Langages d'exploitation des bases de données

Depuis mes premières années en tant que programmeur, j'ai dû créer une bonne centaine de bases de données(Oracle et MySQL).

Oui, ça veut dire beaucoup de projets différents.

Je l'avoue, mes premières bases de données étaient louches et seraient de bons candidats d'études pour montrer les erreurs typiques à ne pas faire.

Heureusement, un programmeur s'améliore et ses réalisations aussi. J'ai donc décidé d'expliquer ma "naming convention" pour mes tables SQL.

Voici un exemple complet.

CREATE TABLE employe (
    id                     INT,
    id_departement         INT,
    nom                    VARCHAR(20),
    poste                  VARCHAR(15),
    CONSTRAINT pk_employe  PRIMARY KEY (id),
    CONSTRAINT fk_emp_dept FOREIGN KEY (id_departement) REFERENCES departement(id)
);

Les points clés :

1 - Ne pas utiliser d'abréviation pour le nom des colonnes et des tables
Le nom d'une table doit être clair. Dans une grande base de données, un nom de table comme EMP pourrait être ambigu. Est-ce une table sur les employés ou sur les emplois ? Dans l'incertitude, un développeur doit interroger la table pour comprendre ce qu'elle contient.

C'est un temps inutilement perdu.


2 - Les clés primaires et étrangères sont pratiquement toujours sur numériques
Imaginons une base de données d'un forum de discussion. La table USAGER contient la colonne courriel. Puisque ce champ est UNIQUE, il est candidat à être la clé primaire. Si tel était le cas, les autres tables ayant une dépendance comme la table MESSAGE auraient donc une clé étrangère pointant vers le courriel.

Que se passe-t-il si l'usager change son courriel ? On doit alors aller mettre à jour les clés étrangères également... pas cool...

En utilisant un ID numérique, interne et souvent non exposé à l'usager, on évite ce genre de problèmes. Peu importe ce que l'usager fera, l'ID ne changera jamais.


3- Le nom des contraintes et des index sont définis
Lorsqu'il y a une violation de contrainte à l'exécution d'une requête, il est beaucoup plus pratique de voir que c'est fk_emp_dept qui est efreinte que la contrainte SYS_C3453243.

En effet, on y verrait immédiatement que c'est la clé étrangère (fk), colonne departement(dept) de la table employe(emp), qui est enfreinte. Autrement, bonne chance avec ce qui suit :

integrity constraint (XYZ.SYS_C1067074) violated

J'utilise le préfixe fk_ pour les clés étrangères, pk_ pour les clés primaires, idx_ pour les index et uq_ pour les clés uniques. Ensuite vient le nom de la table et ensuite le nom de la colonne. Étant donné une limitation de la longueur du nom des contraintes dans MySQL, j'utilise des abréviations. Par exemple : fk_emp_dept.


4 - Nom de table singulier/pluriels
Je préfère ne pas embarquer là dedans... c'est un sujet chaud et il y a beaucoup à lire là dessus sur le Web. Mon avis : définissez-vous une convention et gardez-là.


Voici donc la base de ce que j'ai en tête lorsque je nomme mes tables. Je suis certains que plusieurs d'entre vous utilisent des conventions différentes.

Si jamais vous avez des commentaires ou utilisez d'autres standards pour nommer vos tables et aimeriez en faire bénéficier vos confrères informaticiens, n'hésitez pas à écrire plus bas !