Pourquoi spécifier des attributs de clé primaire / étrangère dans les noms de colonne

Question

Quelques questions récentes ont porté sur les stratégies de nommage des colonnes. J'ai été plutôt surprise de découvrir le concept d’incorporation de la notion de clé étrangère et de clé primaire dans les noms de colonne. C'est

select t1.col_a, t1.col_b, t2.col_z
from t1 inner join t2 on t1.id_foo_pk = t2.id_foo_fk

Je dois avouer que je n'ai jamais travaillé sur un système de base de données utilisant ce type de système, et je me demande quels sont les avantages. D'après ce que je vois, une fois que vous avez appris les N tables principales d'un système, vous écrivez plusieurs ordres de grandeur avec plus de demandes avec ces tables.

Pour devenir productif en développement, vous devez savoir quelles tables sont les tables importantes et quels sont les simples affluents. Vous aurez envie de mettre en mémoire un bon nombre de noms de colonnes. Et l’une des tâches de base consiste à joindre deux tables ensemble. Pour réduire l’apprentissage, le plus simple est de s’assurer que le nom de la colonne est identique dans les deux tableaux:

select t1.col_a, t1.col_b, t2.col_z
from t1 inner join t2 on t1.id_foo = t2.id_foo

Je suppose qu’en tant que développeur, il n’est pas nécessaire de vous rappeler que les colonnes sont des clés primaires, des clés étrangères et des clés nuls. Il est assez facile de regarder le schéma si vous êtes curieux. Quand on regarde au hasard

tx inner join ty on tx.id_bar = ty.id_bar

... est-il si important de savoir laquelle est la clé étrangère? Les clés étrangères ne sont importantes que pour le moteur de base de données lui-même, afin de lui permettre d'assurer l'intégrité référentielle et d'agir correctement lors des mises à jour et des suppressions.

Quel problème est résolu ici? (Je sais que c'est une invitation à discuter et n'hésitez pas à le faire. Mais en même temps, je suis à la recherche d'une réponse, car il se peut que je manque vraiment quelque chose ».

Answer 1

Je suis d'accord avec vous pour dire que la colonne de clé étrangère d'une table enfant devrait porter le même nom que la colonne de clé primaire de la table parent. Notez que cela permet une syntaxe comme celle-ci:

SELECT * FROM foo JOIN bar USING (foo_id);

Le mot-clé USING suppose qu'une colonne existe sous le même nom dans les deux tables et que vous souhaitez une équi-jointure. C'est bien d'avoir ce raccourci disponible pour les plus bavards:

SELECT * FROM foo JOIN bar ON (foo.foo_id = bar.foo_id);

Notez cependant que dans certains cas, vous ne pouvez pas nommer la clé étrangère de la même manière que la clé primaire à laquelle elle fait référence. Par exemple, dans une table qui a une auto-référence:

CREATE TABLE Employees (
  emp_id INT PRIMARY KEY,
  manager_id INT REFERENCES Employees(emp_id)
);

De même, une table peut avoir plusieurs clés étrangères dans la même table parent. Il est utile d’utiliser le nom de la colonne pour décrire la nature de la relation:

CREATE TABLE Bugs (
  ...
  reported_by INT REFERENCES Accounts(account_id),
  assigned_to INT REFERENCES Accounts(account_id),
  ...
);

Je n'aime pas inclure le nom de la table dans le nom de la colonne. J'évite également l'obligation "& id; id" comme nom de la colonne de clé primaire dans chaque table.

Answer 2

Je suis d'accord avec vous. Mettre cette information dans le nom de la colonne rappelle l’idiotie hideuse de la notation hongroise des premiers jours de Windows.

Answer 3

J'ai adopté la plupart des idées proposées ici au cours des 20 années que j'ai développées avec des bases de données SQL, je suis gêné. La plupart d’entre eux n’ont apporté que peu ou aucun des avantages escomptés et, avec le recul, une douleur au cou.

Chaque fois que j'ai passé plus de quelques heures avec un schéma, je me suis assez rapidement familiarisé avec les tables les plus importantes et leurs colonnes. Une fois que cela a pris quelques mois, j'avais à peu près tout dans ma tête.

À qui cette explication est-elle destinée? Quelqu'un qui ne passe que quelques minutes avec le design ne va pas faire quoi que ce soit de toute façon. Quelqu'un qui envisage de travailler dessus depuis longtemps l'apprendra si vous nommez vos colonnes en sanscrit.

En ignorant les clés primaires composées, je ne vois pas pourquoi quelque chose d'aussi simple que "id". ne suffira pas pour une clé primaire et " _id " pour les clés étrangères.

Ainsi, une condition de jointure typique devient customer.id = order.customer_id .

Lorsqu'il existe plus d'une association entre deux tables, je serais enclin à utiliser l'association plutôt que le nom de la table, donc "quot_ parent_id" peut-être. et " child_id " plutôt que " parent_person_id " etc

Answer 4

J'utilise uniquement le nom de table avec un suffixe Id pour la clé primaire, par exemple. CustomerId, et les clés étrangères référençant celles d'autres tables s'appelleraient également CustomerId. Lorsque vous référencez dans l'application, la table devient évidente à partir des propriétés de l'objet, par exemple. Customer.TelephoneNumber, Customer.CustomerId, etc.

Answer 5

J'ai utilisé " fk_ " au début de toute clé étrangère pour une table, principalement parce que cela m’a aidé à la garder droite lors du développement de la base de données pour un projet dans mon magasin. N'ayant pas fait de travail dans la base de données dans le passé, cela m'a aidé. Avec le recul, je n’avais peut-être pas besoin de le faire, mais c’était trois caractères insérés dans des noms de colonnes et je n’ai pas transpiré.

En tant que nouveau venu dans l'écriture d'applications DB, j'ai peut-être pris quelques décisions qui feraient frémir le développeur, mais je ne suis pas sûr que la clé étrangère soit vraiment un si gros problème. Encore une fois, j’imagine que c’est une différence de point de vue sur cette question et je vais certainement prendre ce que vous avez écrit et cogiter dessus.

Ayez un bon!

Answer 6

Je suis d'accord avec vous. J'adopte une approche différente de celle recommandée dans de nombreux environnements d'entreprise:

Nommez les colonnes au format TableNameFieldName . Ainsi, si j'avais une table Customer et que UserName était l'un de mes champs, ce champ s'appellerait CustomerUserName. Cela signifie que si j'avais une autre table appelée Invoice et que le nom d'utilisateur du client était une clé étrangère, je l'appellerais InvoiceCustomerUserName et, lorsque je la référencerais, je l'appellerais Invoice.CustomerUserName, qui me dirait immédiatement dans quelle table il se trouve.

De plus, cette dénomination vous aide à garder une trace des tables dont vos colonnes proviennent lorsque vous vous connectez.

J'utilise uniquement FK_ et PK_ dans les noms réels des clés étrangères et primaires du SGBD.