Outils pour utilisateurs
Table des matières
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
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
Références
- les 12 règles de Codd et notamment la règle 1 : l’unicité
