Ce que j’aurais aimé que quelqu’un me dise à propos de Postgres

Ce que j’aurais aimé savoir sur Postgres

• L’ampleur de la documentation Postgres : la documentation officielle de Postgres est excellente, mais son volume est tel qu’il est difficile pour un·e ingénieur·e débutant·e de la lire du début à la fin.

Normalisation des données

• Normalisation des données : c’est le processus qui consiste à éliminer les données redondantes dans un schéma de base de données. Par exemple, il vaut mieux ne pas mettre une colonne user_email dans la table documents, et la relier plutôt à la table users via une clé étrangère.
• La nécessité de la dénormalisation : il peut parfois être nécessaire de dénormaliser pour lire certaines données plus rapidement. Mais les données dénormalisées ont un coût : incohérences possibles et complexité accrue à l’écriture.

Suivre les conseils des créateurs de Postgres

• La liste des « choses à ne pas faire » du Wiki Postgres : le Wiki officiel de Postgres contient une liste des « choses à ne pas faire ». Même sans tout comprendre, cela peut aider à éviter des erreurs.
• Recommandations : utiliser le type text pour stocker tout le texte, les types timestampz/time with time zone pour tous les horodatages, et nommer les tables en snake_case.

Particularités courantes de SQL

• SQL n’est pas sensible à la casse : les mots-clés SQL ne distinguent pas majuscules et minuscules. Cela ne se limite pas à Postgres.
• La particularité de NULL : dans SQL, NULL signifie « inconnu » et, combiné à la plupart des opérateurs, le résultat devient NULL. On peut comparer NULL avec des opérateurs comme IS NULL et IS NOT NULL.

Rendre psql plus utile

• Améliorer la lisibilité de la sortie : on peut configurer un pager de terminal pour mieux visualiser les sorties longues. less peut être utilisé comme pager.
• Clarifier les NULL ambigus : dans psql, on peut définir la chaîne qui représente NULL afin qu’il apparaisse plus clairement dans la sortie.
• Utiliser l’autocomplétion : psql prend en charge l’autocomplétion, ce qui facilite la saisie des mots-clés SQL ou des noms de tables.

L’effet de l’ajout d’index

• Définition d’un index : un index est une structure de données qui aide à retrouver rapidement des données.
• Limites des index : si une base de données locale contient très peu de lignes, les index peuvent être peu utiles. Quand on indexe plusieurs colonnes, l’ordre est important.

L’usage de JSONB

• Avantages et inconvénients de JSONB : Postgres fournit des fonctionnalités permettant de stocker et d’interroger efficacement du JSON, mais une mauvaise utilisation peut dégrader les performances.
• Limites structurelles de JSONB : une colonne JSONB n’offre aucune garantie sur la structure et s’auto-documente donc moins bien qu’un schéma de table standard.

Autres conseils utiles

• Problèmes liés aux transactions longues : si une transaction dure trop longtemps, elle peut empêcher d’autres clients d’accéder à la base de données.
• Les puissantes fonctionnalités de Postgres : Postgres offre des atouts proches de ceux des bases de données orientées documents et permet, via JSONB, de stocker et d’interroger efficacement les données.

[bbulbum]

J’aimerais bien lire un jour ce qu’il ne faut pas faire.

[GN⁺]

Commentaires sur Hacker News

• Postgres distingue les majuscules des minuscules, mais écrire les mots-clés en majuscules dans les requêtes sert surtout à améliorer la lisibilité. Ce n’est pas obligatoire, mais il est utile de formater les requêtes pour qu’elles soient plus faciles à lire lors du débogage

  • Comme pour le formatage du code dans d’autres langages, une indentation cohérente, par exemple, réduit le temps de compréhension et permet de se concentrer sur l’essentiel
  • On préférerait éviter d’utiliser des majuscules dans des identifiants comme actuallyUsingCaseInIdentifiers

• J’ai découvert pour la première fois l’entrée wiki « Don’t Do This », et elle est très utile

• Une grande partie du contenu n’est pas propre à Postgres (par exemple, les bizarreries de null, l’ordre des colonnes d’index, etc.)

  • Par exemple, la façon dont null interagit avec les index et les contraintes d’unicité n’est pas intuitive non plus dans MySQL
  • Si une table utilisateur contient une colonne email qui n’autorise pas null et une colonne username qui l’autorise, avec une contrainte d’unicité comme (email, username), on peut insérer plusieurs fois le même e-mail avec un nom d’utilisateur null

• Il faut aborder avec prudence le conseil consistant à normaliser les données

  • L’auteur a mentionné 10 formes de normalisation différentes, mais la plupart des gens n’ont pas besoin d’en utiliser 7

• J’aimerais que les développeurs se préoccupent davantage de la normalisation et arrêtent de tout mettre dans des colonnes JSON(b)

• Le mot « parcours » paraît désagréable dans les blogs à force d’être surutilisé

• Les sections de code sont si peu pratiques sur mobile qu’il est presque impossible de les faire défiler

• Dans la spécification JSON, null est une valeur constante, différente de NULL en SQL

• Ajouter un index peut n’avoir absolument aucun effet

  • Certains aspects de la philosophie de Postgres sont trop rigides ou difficiles à comprendre
  • J’espère qu’une prise en charge des hints sera ajoutée dans une future version

• Lire ce type d’article et en comprendre 90 % donne un sentiment de fierté vis-à-vis des postes que l’on a occupés