Conventions de nommage des noms de colonne et meilleures pratiques

19

J'aimerais avoir un avis d'expert sur les meilleures pratiques en matière de dénomination des colonnes .

L'arrière-plan est que, selon Wikipedia , la syntaxe suivante,

SELECT ... FROM Employees JOIN Timesheets USING (EmployeeID);

est plus efficace que

SELECT ... FROM Employees JOIN Timesheets ON (Employees.EmployeeID = Timesheets.EmployeeID);

Cependant, la JOIN ... USINGsyntaxe ne fonctionne que pour toutes les colonnes de clé primaire qui ont des noms globalement uniques . Je me demande donc si cela est considéré comme la bonne chose à faire.

Personnellement, je créais toujours des tables avec une colonne PK idet une colonne de clé étrangère othertable_id. Mais de cette façon, il n'est pas possible d'utiliser USINGou NATURAL JOIN.

Tout lien vers des styles de conception ou des guides de bonnes pratiques pour la conception de tables serait également apprécié!

database-design join naming-convention

— Kerrek SB
source

3

Wikipedia a tort. La première version n'est en aucun cas plus efficace que la seconde. Sous le capot, la base de données créera des requêtes

— absolument

13

Cela a déjà été demandé sur SO.

Lorsque vous avez des noms communs et très ambigus, puis préfixez le nom de la table. Autrement dit, tout ce que vous êtes susceptible d'avoir à alias dans presque toutes les requêtes.

Donc, pour une table des employés, j'aurais

EmployeeID
EmployeeName
Comment
Salary
StartDate
EndDate
InsertedDateTime
...

Et Wikipedia dit en fait:

Cependant, la construction USING est plus qu'un simple sucre syntaxique, car l'ensemble de résultats diffère de l'ensemble de résultats de la version avec le prédicat explicite. Plus précisément, toutes les colonnes mentionnées dans la liste USING n'apparaîtront qu'une seule fois, avec un nom non qualifié, plutôt qu'une seule fois pour chaque table de la jointure.

C'est une colonne de moins. Vous n'utiliseriez jamais de SELECT *toute façon, donc le point est sans objet ...

— gbn
source

Je n'avais pas pensé à chercher SO - idiot moi. Avez-vous des liens vers des questions SO particulièrement bonnes? Quoi qu'il en soit, merci, je m'en tiendrai désormais à la dénomination "ID unique"!

— Kerrek SB

@Kerrk SB: en fait, je ne l'ai pas fait. J'ai tendance à les ignorer parce que chacun obtient une réponse ou se ferme rapidement :-) Désolé

— gbn

Je voudrais voir ces questions similaires sur SO, si quelqu'un peut trouver un lien. Je suis venu ici parce que je n'ai pas pu trouver de question là-bas, et j'étais sûr qu'elle aurait déjà été posée. J'ai tout de suite trouvé cette question.

— Nicholas Shanks

C'était sur programmers.SE. Un beau gros combat pour vous ... programmers.stackexchange.com/questions/114728/…

— gbn

6

Le livre suivant parle de l'utilisation de l'ID comme antipattern SQL et je suis d'accord avec l'auteur que c'est. http://www.amazon.com/SQL-Antipatterns-Programming-Pragmatic-Programmers/dp/1934356557/ref=sr_1_1?s=books&ie=UTF8&qid=1330025134&sr=1-1

Il s'agit d'un problème particulier lorsque vous effectuez des rapports complexes et que vous avez besoin de plusieurs identifiants, car vous devez alors créer un alias. L'utilisation de l'ID de nom de table facilite également l'identification du FK correct auquel se joindre (car ils ont le même nom) et rend les erreurs de connexion à la mauvaise chose moins probables.

Cela dit, de nombreuses bases de données ne prennent pas en charge la syntaxe USING, ce qui fait que le problème que vous avez soulevé n'est pas un problème pour ces bases de données. si les structures de table changent. Supposons donc que vous ajoutiez un champ appelé modifieddate aux deux tables, vous ne voudriez pas vous y joindre mais la jointure naturelle le ferait.

— HLGEM
source

4

Il est préférable de donner explicitement le nom de la table et le nom de la colonne comme Employees.EmployeeID avec des expressions où une jointure existe

— Eralper
source