Best practises Bases de données

Début 2020, j'ai questionné la liste de diffusion RBDD à propos des bonnes pratiques pour la création/modification et utilisation des bases de données. Après différents échanges (merci aussi à Éric Q), Marie-Claude Q a créé l'article:

Bonnes pratiques en matière de base de données

Certaine de ses bonnes pratiques ne sont pas applicables si vous envisagez d'utiliser un ORM comme Doctrine, le “type” SERIAL n'est par exemple pas pris en compte, la clé primaire n'est pas demandée et sera toujours nommée id

Afin de l'illustrer, voici ce que j'en retiens:

Structure des bases de données

Des constantes

Le nom des bases de données, des schémas, des tables et des attributs doit être

en minuscule

au singulier

sans caractère accentué, sans espace

Il doit être parlant sans être verbeux. L’utilisation d’abréviation est déconseillée.

Les schémas, les tables et les colonnes porteuses d’informations doivent être commentés

Le commentaire doit citer l’unité de mesure, pour les données numériques

Des options

Le nom des objets et le commentaire doivent être en anglais

langue internationale
langue non maitrisée par tous (les nuances mises dans les commentaires peuvent être mal interprétées)

La clef primaire doit être de type « serial » et nommée « table_id »

porte sur une seule colonne et étant de type numérique (donc vrai aussi pour le type integer), c'est plus rapide pour l’indexation
non significative (ne porte pas d'information métier) et l’unicité métier (une seule fois cette personne avec nom-prénom par exemple) de l’enregistrement est à la charge du développeur

La clef étrangère doit avoir le même nom que la clé primaire de la table référente (table_id)

utilisation de jointure de type join using (table_id) mais cela peut rend plus difficile la compréhension du contenu
utilisation de jointure de type join using (table_id) est impossible

Le nom des vues doit être préfixé par « v_ »

plus facile de les repérer
peu d’intérêt de les repérer

Le nom des attributs doit être préfixé par le nom de leur table et séparé par des _ s'il y a une ambiguïté possible avec d'autres tables

lecture des requêtes facilité (absence d’ambiguïté), évite l'utilisation d'alias (cf. §Requêtes)
nom à rallonge

Le nom des tables doit être aliaisé par une abréviation

lecture des requêtes facilité (absence d’ambiguïté) et nom court
pas toujours facile de trouver une abréviation parlante

Les requêtes

L’utilisation de script SQL doit être privilégiée. Il doit être commentés et contenir les entêtes minimum suivantes (auteur / date de création / date de dernière mise à jour / utilité). Il doit être archivé, dans un gestionnaire de version de code si possible, ou dans un système de sauvegarde au moins journalier

Utilisation des alias dans les requêtes complexes

facilite la lecture de la requête

indispensable si la même table est utilisée plusieurs fois dans la même requête (relations multiples)

les alias des tables sont utilisables dans les WHERE, HAVING et autre

compromis à trouver entre longueur de l'alias et signification

les alias des champs ne sont pas utilisables dans les mêmes WHERE, HAVING et autres