Salut à tous,
Dimitri FONTAINE a sortie récemment le livre The Art of PostgreSQL. Il s'agit d'un livre à destination des développeurs, tout en restant assez pointu sur les spécificités et les possibilités de PostgreSQL. L'annonce de la sortie du livre en anglais est passée ici : https://linuxfr.org/users/fero14041/journaux/sortie-de-the-art-of-postgresql-de-dimitri-fontaine .
On y avait d'ailleurs discuté de l'intérêt d'un VF, et bien il semble que l'auteur français veuille tenter la VF : https://theartofpostgresql.com/fr/
Pour info, The Art of PostgreSQL est une version complétée et augmentée de Mastering PostgreSQL for Application Development. Je me suis procuré la table des matières via le site et je la trouve pertinente pour les développeurs qui veulent profiter de PostgreSQL comme un brique intégrée de leur application et pas juste comme une couche de persistence interchangeable.
J'ai un peu de mal à l'idée de payer 50€ de plus pour le pg_dump. Par ailleurs, que se passe-t-il s'il n'y a pas assez de précommandes ?
Bref, je pense pas que Dimitri va faire une VF pour toutes les éditions de son livre. S'il en fait une, c'est l'occasion d'avoir une bonne référence sous le coude, en français, bien que la version papier ne soit pas prévue.
N.B. : Je trouve le marketing autour de ce livre un peu agressif. Néanmoins, je relaie parce que c'est une occasion d'avoir un bon livre en français sur le sujet. Je n'ai pas d'intérêt financier dans cette histoire :-)
# Diverses questions
Posté par freem . Évalué à 3.
Bah, moi, quand je vois un sujet sur les SGBDR, j'ai tendance a ne pas être sympa alors je vais pas trop être d'accord avec l'idée de se spécialiser dans un SGBDR.
Pourquoi?
Parce que, pour moi, comme pour probablement la majorité des gens qui ont besoin d'un stockage de données à relations, les contraintes de perfs ne sont pas fondamentales, ou du moins, pas sur ce sujet.
À mon avis, dans la plupart des cas, il vaut mieux se limiter au truc portable, quitte a y passer un peu plus de temps de dev.
Pourquoi?
Parce qu'un projet jeune ne peut pas savoir ou est le point bloquant en terme de performances, parce que ça, on ne sait le détecter que par la mesure. Pour la perf, je sais juste faire par des mesures statistiques, et des grands m'ont inspiré ma méthode (je sais, je suis bien moins bon que ces gens).
Tant qu'on a pas de besoins précis, il vaut mieux rester portable, pour moi.
Pourquoi?
Un ingénieur qui ne sait pas faire un truc portable, c'est juste un gêneur. Un code portable, ça permets de détecter plus de problème, en le passant au travers de plus d'alternatives.
Ça permets aussi, le jour ou il y a un problème de performances, de choisir une alternative spécialisée dans la résolution du problème de performances réellement rencontré, et non supposé au début par un fanboy.
Ma conclusion: ce livre peut être bien à lire, pour des gens qui maîtrisent déjà le SQL, et cette maîtrise, je ne l'ai pas encore vue: moi, je suis franchement bof, et la plupart des gens que j'ai rencontrés ne savent pas proposer une API publique en SGBDR qui soit portable, voire même ont du mal a utiliser le SQL de base, et compensent ce mal en utilisant les surcouches spécifiques du moteur qu'ils utilisent.
[^] # Re: Diverses questions
Posté par Étienne BERSAC (site Web personnel) . Évalué à 10.
Des problèmes de performances avec les données, on en a à la pelle. Je comprends ton point de vue pour des sites simples. Pour des fonctionnalités métiers, c'est différent.
Je pense par exemple à des ERP, qui essaient d'être portable pour ne pas l'être au final. Ce qui aboutit au pire des deux mon monde : surcouche lourde, utilisation naïve du SGBDR.
Beaucoup de progiciels se retrouvent couplés à un SGBDR parce qu'à un moment, le SQL naïf et portable n'était pas suffisant.
Enfin, ne me fait pas dire ce que je n'ai pas dit. Beaucoup de dév et d'ORM utilise le SQL des années 90. Aujourd'hui, le SQL a beaucoup évolué : aggrégats, JSON, CTE, window function. On peut déjà avoir pas mal d'avantages à se rapprocher du SGBD, tout en restant dans du SQL portable (à quelques alias près).
La performance est une fonctionnalité. Un produit utile rencontre vite des limites en termes de performances où le SGBD n'est qu'un élément du problème. C'est dommage de nier le problème dès le début. Quand on choisit un SGBD, mieux vaut prendre celui qui permettra de résoudre les problèmes qu'on rencontrera plus tard, plutôt que celui qui sera lui-même le problème plus tard.
[^] # Re: Diverses questions
Posté par benoar . Évalué à 9.
Tu fais de très bonnes remarques. Je pense qu'il faut y ajouter malheureusement le classique penchant des devs pour la programmation procédurale et « l'incompréhension » du SQL : quand freem fait justement remarquer que la plupart des devs se limitent à du SQL simple (ou en utilisant des surcouches spécifiques, souvent façon procédural), c'est parce qu'ils ont un cerveau formaté à ce type de réflexion, et ne savent pas exploiter ce qui fait la puissance de SQL. Et je ne parle même pas des fonctions avancées !
J'ai appris le SQL pendant mes études, et heureusement qu'il y a des cours sur ce langage standard (et avec la théorie relationnelle de Codd, c'est mieux !) plutôt que des N couches qui sont apparues et disparues depuis des dizaines d'années ! C'est sûr que 90% des devs ne comprendront pas l'intérêt du SQL « brut », mais c'est toujours intéressant de se conformer à d'autres paradigmes. J'ai également fait du Prolog, et ça ouvre l'esprit à tellement de manière d'aborder les problèmes différentes ! J'ai par exemple fait un « factorisateur » de données GTFS uniquement en SQL, et je n'ai aucune idée de comment j'aurais pu faire ça simplement en procédural ! Pourtant j'adore le C.
Et puis aussi la tendance à vouloir toujours tout abstraire jusqu'à l'absurde. Je comprends la peur de se retrouver lié à un soft très particulier, mais franchement il y a moyen de faire du SQL 95% standard sur du PostGres par exemple (perso je commence avec du sqlite, mais toujours en pensant à du SQL standard ; j'ai été formé sur Oracle pourtant…), qui ne nécessitera qu'un tout petit effort de portage si jamais on en a besoin (ça évite le classique over-engineering d'abstraire même la base SQL qui est pourtant à la base un langage standardisé !).
[^] # Re: Diverses questions
Posté par freem . Évalué à 2.
Merci, mais je suis pas dev web, et les BDD, ça sert pas juste a faire des sites.
Seulement certaines. Ou alors, tu considères qu'un système autonome, doté d'une "faible" puissance de calcul et espace disque n'est pas un logiciel métier? Dans ce cas, c'est quoi, un logiciel métier? Pour moi, ça a toujours fait parties du vocable commercial, tout comme devops, agilité, méthode en V, etc etc. J'ai remarqué qu'il est rare d'avoir une définition précise de la part des gens qui en parlent, et j'ai pas encore vu de gens qui les ont vécu. Si c'est la jeunesse, j'aimerai que ça dure, je pourrais ainsi être immortel :D
Utilisation naïve d'un outil qui est, en réalité, ultra spécifique et dont la gestion est un métier a part entière.
Un maçon peut avoir des notions de couverture, ça suffira pour les cas simples, mais c'est tout.
C'est pareil pour nous, développeurs. On peut être informaticiens, ça veut pas dire qu'on sait gérer toutes les situations liées à l'info… mais je pense que tu le sais.
Et la question qui tue: ils sont vraiment portables? Je suis sûr que non.
De ce que j'en sais, la portabilité à des propriétés évidentes, notamment la détection d'erreurs par rapport au standard, mais elle implique des sacrifices.
Notamment, un code portable sera moins rapide et moins performant qu'un code spécialisé, c'est logique.
Ce qui est certain, c'est que si on me dit qu'il faut préférer la portabilité à la maintenabilité, je démissionne mentalement. Parce que pour moi la maintenabilité doit être une conséquence de la portabilité. Le code histo du style que les gars de crosoft se tapent (j'ai un grand respect pour eux, vraiment) j'aimerai vraiment y avoir affaire, mais au moins, ça s'explique par 40 ans de code.
Accessoirement, la complexité du code, ça risque juste de rendre le-dit code plus lent, surtout s'il faut être portable.
Mes excuses si c'est ce que j'ai fait. Si je l'ai fait, c'était involontaire, je n'ai pas du bien comprendre ce que tu voulais dire, et je te prie de m'en excuser.
Pour être précis, je garde en tête le SQL92, c'est peut-être une mauvaise chose, mais, quel est le dernier standard supporté par tous les SGBDR qui ont eu une nouvelle version ces 10 dernières années?
Je suis heureux de l'apprendre. Tu aurais un lien qui me permettrais de m'aider a me mettre a niveau? J'aime pas le SQL, mais j'aime encore moins faire de la merde, et le SQL est partie intégrante de la plupart des logiciels qui ont des données assez complexes pour qu'un
awkne puisse les traiter aisément.Tout à fait. Comme le sont la portabilité ou la fiabilité, d'où la naissance du Not Only SQL (que je ne connais quasi que de nom) il y a quelques années: parce que les SGBDR, ça se met mal à l'échelle, mais ça a des propriétés super sympa quand on veut être sûr du comportement.
Je pense qu'on est plus ou moins du même bord sur la plupart des points, mais sur celui-ci, je diffère.
Que le SGBD[R] soit juste un élément dans la chaîne, je suis d'accord, c'est juste un fait.
Nier le problème dès le début implique de savoir que le problème sera la, et, perso, je n'ai rencontré que des développeurs qui ont un certain amour de leur boulot, et les problèmes connus dès le début sont plus que rares. Ceux qui apparaissent par la suite semblent majoritaires.
Du coup, je crois que d'abord viser la généricité et une archi correcte est la clé. Parce que la plupart des problèmes que j'ai vus pour l'instant sont liés à de mauvaises architectures, une mauvaise découpe du problème.
Après, il me reste beaucoup a apprendre, et plus j'en apprend, plus je vois le fossé qui me sépare des bons…
Et comment tu sais, sans mesure? Accessoirement, essayer tous les SGBD, ça prend du temps, faut dont se fier aux… benchmarks…. qui sont tous plus spécifiques les uns que les autres.
Perso, je préfère aller dans un truc portable au début, et quand les perfs foirent, alors ok, je vais vers du spécifique. Comme dans mon langage préféré, en fait, comme en C++.
[^] # Re: Diverses questions
Posté par YBoy360 (site Web personnel) . Évalué à 1.
Les ERP utilisent souvent (tous?) des ORM, donc la logique métier doit pouvoir se faire hors du SGBD … On peut utiliser du JSON avec les ORM Modernes (ce qui est déconseillé, même sans ORM).
Enfin, rien empêche de faire du SQL pure directement, sans passer par l'ORM pour utiliser les aggrégats par exemple. Il est possible de mixer les 2 approches.
[^] # Re: Diverses questions
Posté par freem . Évalué à 3.
Ce type de phrase m'agace.
Déconseiller un truc, c'est bien, mais sans dire pourquoi, c'est mal, ça empêche des gens de réfléchir, ça force les autres a faire une recherche intellectuelle coûteuse en temps. D'un autre côté, p'tet que forcer les autres a faire cette recherche est une bonne chose, va falloir que j'y songe.
[^] # Re: Diverses questions
Posté par YBoy360 (site Web personnel) . Évalué à 3.
OK, par exemple postgresql-anti-patterns-unnecessary-jsonhstore-dynamic-columns
Nous sommes passé par du JSONB à rien, c'est à dire à stocker le JSON dans des chaînes de caractères. Et nous limitons le JSON au maximum : uniquement pour gérer les différence entre les versions d'un même objet.
Nous utilisons un ORM qui supportent le JSON, les aggrégats, qui permet de résoudre bien des problèmes de performances en configurant le fectch des objets, mais nous utilisons aussi massivement des procédures stockées, alors je pense qu'utiliser un ORM n'est pas contradictoire avec bien connaître son SGBD.
[^] # Re: Diverses questions
Posté par freem . Évalué à 3. Dernière modification le 19/11/19 à 20:29.
Quelle tristesse, utiliser du JSON dans un varchar de SGBDR… J'espère que le Not-Only SQL a permis de réduire ce genre de choses?
Bien connaitre ses outils n'est jamais une mauvaise chose, moi qui aime rentrer dans les choses bas niveau je serai mal placé pour dire le contraire.
Par contre, je pense qu'avant ça, il vaut mieux connaître les généralités communes à tous les outils d'un type donné, par exemple bien connaître le SQL avant de partir à faire des procédures stockées, ne serait-ce que parce qu'une PS sera moins idiomatique qu'une requête (et peut-être même moins performante, mais je manque d'expérience pour l'affirmer).
Par contre, les PS offrent l'avantage de ne pas avoir de SQL directement embarqué dans le code utilisateur, ça fait une API plus clean, plus simple à modifier, à réutiliser, à documenter. Je n'ai pas encore d'avis bien déterminé si je préfère lire une requête sur des tables ou sur une PS par contre.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.