PostgreSQL : les procédures stockées

Bonjour,

Dans ma composition d'un petit CMS maison je peux vous dire que j'en apprends des trucs ! Tous les jours ! Et du coup je viens de tomber sur un concept SQL dont j'avais vaguement entendu parler mais sans jamais m'y intéresser jusque là : les procédures stockées.

Ça a l'air super puissant comme truc, tellement puissant que je me pose la question de savoir pourquoi je ne les vois jamais apparaître dans les articles et tutoriels que je consulte... Peut-être parce que justement ce ne sont que des tutoriels et articles d'introduction ? Peut-être aussi, nous sommes profondément entré dans une ère de code "sans opinions", où les BDD sont interchangeables ?

Bref : au quotidien, dans la vraie vie, ces procédures stockées, vous vous en servez ou pas ? Il y a peut-être des écueils à connaître ?
Modifié par Olivier C (06 Apr 2024 - 21:17)

Hello !

Je pense qu'on en parle pas beaucoup car c'est un concept plutôt avancé et car les développeurs ont l'habitude d'implémenter ces procédures dans l'application connectée directement. Et c'est personnellement ce que j'ai fais aussi.

Je sais qu'elles sont plus utilisées dans des secteurs critiques comme les banques, la gestion de trafic aérien, le médical, et tous ces autres domaines où l'intégrité des données est cruciale et l'erreur n'est pas permise.

Les bases de données ne devraient jamais être interchangeables à mon humble avis. Ça paraît évident quand on compare une base de données SQL et NoSQL, mais si on compare MySQL avec PostgreSQL par exemple, on se rend vite compte qu'elles sont pas interchangeables si ont exploite leurs spécificités.

En parlant de spécificité, je sais pas si tu savais, mais PostgreSQL permet de faire de l'héritage entre tables. Et ça c'est vraiment puissant aussi.

Ouais, PostgreSQL > all

EDIT: Puisque tu t'intéresse apparement activement à ça en ce moment, jette un coup d'oeil aussi aux concepts des vues, et des vues matérialisées si ça ne te dis rien
Modifié par Anymah (06 Apr 2024 - 22:19)

Merci pout ton retour Anymah.

Je suis d'accords avec l'aspect non interchangeable d'une BDD, du moins si l'on ne veut pas rester sur un aspect très superficiel des fonctionnalités. Du coup tu m'as donné encore plus envie de me coltiner les procédures stockées : si c'est bon pour Airbus alors c'est bon pour moi (oui, l'égo...) ! À mon niveau potentiel de trafic ridicule c'est sans doute de la micro optimisation, mais j'aime bien cette idée de requêtes déjà en cache que l'on a plus qu'à appeler du côté de l'application. Surtout : je me suis toujours dis que la vraie valeur ajouté de ce que je peux coder, c'est du côté de la BDD que ça ce passe. Node.js, Express, Fastify, etc - même si j'adore ces technos et frameworks JS - ne sont que des interfaces secondaires en comparaison : la vraie valeur ajoutée, ce sont les données et leur intégrité. Voilà pourquoi je choisis Postgres.

De même, pas d'ORMs : trop de modes (il fallait absolument utiliser Sequelize, et maintenant Prisma...) alors que le SQL c'est d'une puissance... Je suis totalement en phase avec ce que dit ce type :

"Thibault Jouannic" a écrit :
J'aime Postgresql, le moteur de base de données le plus ennuyeux au monde. Une technologie tellement fiable et éprouvée que tous les cool kids essayent absolument de la remplacer par autre chose.

Au fait, j'ai aperçu de loin (là aussi) les vues matérialisées. Merci. Là aussi il faudra que je prenne du temps. Avec le SQL je vais procéder par étapes : j'installe une première base fonctionnelle et puis d'itérerai et optimiserai après coup, à mesure que je monterai en compétence sur la techno.

Rien que maintenant, je me suis penché sur l'implémentation d'une petite fonction recherche et j'ai codé rapidement un truc fonctionnel (mais pas optimisé). Mais en réalité Postgres possède déjà, de manière intégré, des fonctionnalités de recherche "plain text" tellement performantes qu'elles permettent de se passer de technos telle qu'elasticssearch. C'est ça que j'aime avec Postgres.
Modifié par Olivier C (07 Apr 2024 - 18:14)

Olivier C a écrit :
Rien que maintenant, je me suis penché sur l'implémentation d'une petite fonction recherche et j'ai codé rapidement un truc fonctionnel (mais pas optimisé). Mais en réalité Postgres possède déjà, de manière intégré, des fonctionnalités de recherche "plain text" tellement performantes qu'elles permettent de se passer de technos telle qu'elasticssearch.

Oh ! la puissance du truc !

Je suis passé de ça ("level 0", le truc de base en SQL, ultra mal optimisé) :

SELECT _name, _slug
FROM __article
WHERE unaccent(_name) || unaccent(_alternative_headline) || unaccent(_description) || unaccent(_content)
ILIKE $1;

À ça ("level 1") :

SELECT _name, _slug
FROM __article
WHERE to_tsvector('french',_name || _alternative_headline || _description || _content)
@@ plainto_tsquery('french', $1);

Je n'ai pas encore défini d'index, ni de pertinence de "poids" (rank) dans la recherche" pour le tri des articles, mais déjà j'ai mes "lemmes" : une recherche par la racine des mots seulement, ce qui augmente exponentiellement la pertinence d'une requête.

De plus il n'y a plus rien à faire côté app', plus rien à formater en entrée, Postgres s'occupe de tout de manière bien plus optimisée.

I <3 Postgres.
Modifié par Olivier C (08 Apr 2024 - 19:55)