Nommage des colonnes d’ID dans les tables de firebase database

L’ID est un Antipattern SQL. Voir http://www.amazon.com/s/ref=nb_sb_ss_i_1_5?url=search-alias%3Dssortingpbooks&field-keywords=sql+antipatterns&sprefix=sql+a

Si vous avez beaucoup de tables avec un identifiant comme identifiant, cela rend la création de rapports beaucoup plus difficile. Cela obscurcit le sens et rend la lecture des requêtes complexes plus difficile tout en exigeant que vous utilisiez des alias pour différencier le rapport lui-même.

De plus, si quelqu’un est assez stupide pour utiliser une jointure naturelle dans une firebase database où elles sont disponibles, vous vous joindrez aux mauvais enregistrements.

Si vous souhaitez utiliser la syntaxe USING autorisée par certains dbs, vous ne pouvez pas utiliser l’ID.

Si vous utilisez un identifiant, vous pouvez facilement vous retrouver avec une jointure erronée si vous copiez la syntaxe de la jointure (ne me dites pas que personne ne le fait jamais!) Et oubliez de changer l’alias dans la condition de jointure.

Donc, vous avez maintenant

 select t1.field1, t2.field2, t3.field3 from table1 t1 join table2 t2 on t1.id = t2.table1id join table3 t3 on t1.id = t3.table2id 

quand tu voulais dire

 select t1.field1, t2.field2, t3.field3 from table1 t1 join table2 t2 on t1.id = t2.table1id join table3 t3 on t2.id = t3.table2id 

Si vous utilisez tablenameID comme champ d’identification, ce type d’erreur accidentelle est beaucoup moins susceptible de se produire et plus facile à trouver.

J’ai toujours préféré ID à TableName + ID pour la colonne id, puis TableName + ID pour une clé étrangère. De cette façon, toutes les tables ont le même nom pour le champ id et il n’y a pas de description redondante. Cela me semble plus simple car toutes les tables ont le même nom de champ de clé primaire.

Pour ce qui est de joindre des tables et de ne pas savoir quel champ d’identification appartient à quelle table, à mon avis, la requête doit être écrite pour gérer cette situation. Là où je travaille, nous préfions toujours les champs que nous utilisons dans une instruction avec l’alias de table / table.

Il y a eu un combat de nerd à ce sujet dans mon entreprise récemment. L’avènement de LINQ a rendu le motif de nom de table + ID redondant encore plus évident à mes yeux. Je pense que la plupart des gens raisonnables diront que si vous écrivez votre SQL de telle manière que vous devez spécifier des noms de tables pour différencier les FK, ce n’est pas seulement une économie de frappe, mais cela ajoute de la clarté à votre SQL à utiliser. l’ID dans lequel vous pouvez clairement voir quel est le PK et quel est le FK .

Par exemple

FROM Employés e LEFT JOIN Clients c ON e.ID = c.EmployeeID

me dit non seulement que les deux sont liés, mais qui est le PK et qui est le FK . Alors que dans l’ancien style, vous êtes obligé de regarder ou d’espérer qu’ils ont bien été nommés.

Nous utilisons InvoiceID , pas d’ ID . Cela rend les requêtes plus lisibles – quand vous voyez un ID seul, cela peut vouloir dire quelque chose, surtout quand vous alias la table avec i .

Je suis d’accord avec Keven et quelques autres personnes ici que le PK pour une table devrait simplement être Id et les clés étrangères listent OtherTable + Id.

Cependant, je souhaite append une raison qui a récemment donné plus de poids à cet argument.

Dans ma position actuelle, nous utilisons le framework d’entités utilisant la génération POCO. En utilisant la convention de dénomination standard de Id, le PK permet l’inheritance d’une classe poco de base avec validation et ce, pour les tables partageant un ensemble de noms de colonnes communs. L’utilisation de Tablename + Id en tant que PK pour chacune de ces tables détruit la possibilité d’utiliser une classe de base pour ces tables.

Seulement un peu de matière à reflection.

Ce n’est pas vraiment important, vous risquez de rencontrer des problèmes similaires dans toutes les conventions de nommage.

Mais il est important d’être cohérent afin de ne pas avoir à regarder les définitions des tables chaque fois que vous écrivez une requête.

Ma préférence est également l’ID pour la clé primaire et l’ID de table pour la clé étrangère. J’aime aussi avoir une colonne “name” dans la plupart des tableaux où je détiens l’identifiant lisible par l’utilisateur (c.-à-d. Le nom :-)) de l’entrée. Cette structure offre une grande flexibilité dans l’application elle-même, je peux manipuler des tables en masse, de la même manière. C’est une chose très puissante. Généralement, un logiciel OO est construit sur la firebase database, mais le jeu d’outils OO ne peut pas être appliqué car la firebase database ne le permet pas. Avoir les colonnes id et name n’est toujours pas très bon, mais c’est une étape.

Sélectionner
i.ID, il.ID De factures i gauche Rejoindre InvoiceLines il sur i.ID = il.InvoiceID

Pourquoi je ne peux pas faire ça?

 Select Invoices.ID , InvoiceLines.ID From Invoices Left Join InvoiceLines on Invoices.ID = InvoiceLines.InvoiceID 

A mon avis, c’est très lisible et simple. Nommer des variables comme je et il est un mauvais choix en général.

Je viens de commencer à travailler dans un endroit qui utilise uniquement “ID” (dans les tables de base, référencées par TableNameID dans les clés étrangères), et qui ont déjà rencontré DEUX problèmes de production directement causés par celui-ci.

Dans un cas, la requête a utilisé “… où ID dans (SELECT ID FROM OtherTable …” au lieu de “… où ID dans (SELECT TransID FROM OtherTable …”).

Est-ce que n’importe qui peut honnêtement dire que cela n’aurait pas été plus facile de repérer si des noms complets et cohérents ont été utilisés où la mauvaise déclaration aurait lu “… où TransID (SELECT OtherTableID de OtherTable …”? Je ne pense pas alors.

L’autre problème se produit lors du refactoring du code. Si vous utilisez une table temporaire alors que précédemment la requête sortait d’une table principale, l’ancien code indiquait “… dbo.MyFunction (t.ID) …” et si cela ne change pas mais que “t” se réfère maintenant à table temporaire au lieu de la table principale, vous n’obtenez même pas d’erreur – juste des résultats erronés.

Si générer des erreurs inutiles est un objective (certaines personnes n’ont peut-être pas assez de travail?), Alors ce type de convention de nommage est génial. Sinon, le nom cohérent est la voie à suivre.

Par souci de simplicité, la plupart des gens nomment la colonne sur l’ID de la table. Si elle a une référence de clé étrangère sur une autre table, alors elle l’appelle explicitement InvoiceID (pour utiliser votre exemple) dans le cas de jointures, vous utilisez de toute façon la pseudonyme pour inv.ID explicite est plus simple que inv.InvoiceID

À partir de cela du sharepoint vue d’un dictionnaire de données formel, je nommerais l’élément de données invoice_ID . Généralement, un nom d’élément de données sera unique dans le dictionnaire de données et aura idéalement le même nom, bien que des termes qualificatifs supplémentaires soient parfois nécessaires, par exemple l’élément de données employee_ID pourrait être utilisé deux fois dans l’organigramme. comme supervisor_employee_ID et subordinate_employee_ID respectivement.

De toute évidence, les conventions d’appellation sont subjectives et une question de style. J’ai trouvé les directives ISO / IEC 11179 comme un sharepoint départ utile.

Pour le SGBD, je vois des tableaux comme des ensembles d’entites (sauf ceux qui ne contiennent qu’une seule ligne, par exemple la table de cofig, la table de constantes, etc.). La convention TableNameID ne fonctionne donc pas pour moi.

J’ai vu le style TableName.ID=PK TableNameID=FK utilisé sur les grands modèles de données et je dois dire que je le trouve un peu déroutant: je préfère de loin que le nom d’un identifiant soit le même, c.-à-d. Quelque chose à noter est le style mentionné ci-dessus qui semble être utilisé dans les magasins qui ajoutent une colonne IDENTITY (auto-incrémentation) à chaque table tout en évitant les clés naturelles et composées dans les clés étrangères. Ces magasins ne disposent généralement pas de dictionnaires de données formels ni de modèles de données. Encore une fois, il ne s’agit que d’une question de style et à laquelle je ne m’abonne pas personnellement. Donc, finalement, ce n’est pas pour moi.

Cela dit, je peux voir un cas où le qualificatif est parfois supprimé du nom de la colonne lorsque le nom de la table fournit un contexte, par exemple l’élément nommé employee_last_name peut devenir simplement last_name dans la table Personnel . La raison en est que le domaine est «noms de famille des gens» et qu’il est plus probable qu’il soit last_name colonnes last_name d’ autres tables plutôt que d’être utilisé comme clé étrangère dans une autre table, mais encore une fois … l’esprit, parfois vous ne pouvez jamais dire. C’est la chose: la modélisation des données est une partie de l’art, une partie de la science.

Personnellement, je préfère (comme cela a été indiqué ci-dessus) le Tableau.ID pour le PK et le TableID pour le FK . Même (s’il vous plaît ne pas me tirer dessus), Microsoft Access recommande ceci.

Cependant, je sais aussi que certains outils de génération privilégient le TableID pour PK car ils ont tendance à relier tous les noms de colonnes contenant «ID» dans le mot, ID INCLUS!

Même le concepteur de requêtes le fait sur Microsoft SQL Server (et pour chaque requête que vous créez, vous finissez par extraire toutes les nouvelles relations inutiles sur toutes les tables de l’ID de colonne).

AINSI que mon OCD interne le déteste, je passe avec la convention TableID . Rappelons qu’il s’agit d’une base de données, car c’est la base de nombreuses applications à venir. Et toutes les technologies devraient bénéficier d’un schéma bien défini avec une description claire.

Il va sans dire que je dessine ma ligne lorsque les gens commencent à utiliser TableName, TableDescription et autres. À mon avis, les conventions doivent faire ce qui suit:

• Nom de la table: Pluriel. Ex. Des employés

• Alias ​​de table: Nom complet de la table, singularisé. Ex.

   SELECT Employee.*, eMail.Address FROM Employees AS Employee LEFT JOIN eMails as eMail on Employee.eMailID = eMail.eMailID -- I would sure like it to just have the eMail.ID here.... but oh well 

[Mettre à jour]

En outre, il existe des messages valides dans ce sujet à propos des colonnes dupliquées en raison du “type de relation” ou du rôle. Exemple, si un Store a un EmployeeID , cela me dit squat. Je fais parfois quelque chose comme Store.EmployeeID_Manager . Bien sûr, c’est un peu plus grand, mais au moins les gens ne vont pas devenir fous en essayant de trouver le gestionnaire de table , ou ce que fait EmployeeID là-bas. Lorsque l’interrogation est WHERE je voudrais simplifier comme suit: SELECT EmployeeID_Manager en tant que ManagerID FROM Store

Je pense que vous pouvez utiliser n’importe quoi pour le “ID” tant que vous êtes cohérent. Inclure le nom de la table est important pour. Je suggère d’utiliser un outil de modélisation comme Erwin pour appliquer les normes et les conventions de dénomination. Ainsi, lors de l’écriture de requêtes, il est facile de comprendre les relations qui peuvent exister entre les tables.

Ce que je veux dire par la première déclaration est que, au lieu de ID, vous pouvez utiliser autre chose comme «recno». Donc, cette table aurait un PK de invoice_recno et ainsi de suite.

Cheers, Ben

Mon vote concerne InvoiceID pour l’ID de table. J’utilise également la même convention de dénomination lorsqu’il est utilisé comme clé étrangère et utilise des noms d’alias intelligents dans les requêtes.

  Select Invoice.InvoiceID, Lines.InvoiceLine, Customer.OrgName From Invoices Invoice Join InvoiceLines Lines on Lines.InvoiceID = Invoice.InvoiceID Join Customers Customer on Customer.CustomerID = Invoice.CustomerID 

Bien sûr, c’est plus long que d’autres exemples. Mais souriez. C’est pour la postérité et un jour, un pauvre codeur junior va devoir modifier votre chef-d’œuvre. Dans cet exemple, il n’y a pas d’ambiguïté et comme des tables supplémentaires sont ajoutées à la requête, vous serez reconnaissant pour sa verbosité.

Pour le nom de la colonne dans la firebase database, j’utiliserais “InvoiceID”.

Si je copie les champs dans une structure non nommée via LINQ, je peux l’appeler “ID” si c’est le seul identifiant de la structure.

Si la colonne ne va PAS être utilisée dans une clé étrangère, de sorte qu’elle ne soit utilisée que pour identifier de manière unique une ligne pour l’édition ou la suppression des modifications, je l’appellerai “PK”.

Si vous donnez à chaque clé un nom unique, par exemple “invoices.invoice_id” au lieu de “invoices.id”, vous pouvez utiliser les opérateurs “join naturelle” et “using” sans aucun souci. Par exemple

 SELECT * FROM invoices NATURAL JOIN invoice_lines SELECT * FROM invoices JOIN invoice_lines USING (invoice_id) 

au lieu de

 SELECT * from invoices JOIN invoice_lines ON invoices.id = invoice_lines.invoice_id 

SQL est suffisamment verbeux sans le rendre plus prolixe.

Ce que je fais pour garder les choses cohérentes pour moi (où une table a une clé primaire de colonne unique utilisée comme ID) est de nommer la clé primaire de la table Table_pk . Partout où j’ai une clé étrangère pointant vers cette clé primaire de tables, j’appelle la colonne PrimaryKeyTable_fk . De cette façon, je sais que si j’ai un Customer_pk dans ma table Customer et un Customer_fk dans ma table Order, je sais que la table Order fait référence à une entrée de la table Customer.

Pour moi, cela a du sens surtout pour les jointures où je pense que cela se lit plus facilement.

 SELECT * FROM Customer AS c INNER JOIN Order AS c ON c.Customer_pk = o.Customer_fk 

FWIW, notre nouveau standard (qui change, euh, je veux dire “évolue”, avec chaque nouveau projet) est:

• Noms de champs en minuscules
• Noms de table en majuscule
• Utilisez des traits de soulignement pour séparer les mots dans le nom du champ – convertissez-les en code Pascal.
• préfixe pk_ signifie clé primaire
• _id suffix signifie un entier, ID à incrémentation automatique
• fk_ prefix signifie clé étrangère (pas de suffixe nécessaire)
• _VW suffixe pour les vues
• is_ préfixe pour booléens

Ainsi, une table nommée NAMES peut avoir les champs pk_name_id, first_name, last_name, is_alive, fk_company et fk_company et une vue appelée LIVING_CUSTOMERS_VW , définie comme suit:

 SELECT first_name, last_name
 DE CONTACT.NAMES
 WHERE (is_alive = 'True')

Comme d’autres l’ont dit, cependant, à peu près tous les schémas fonctionneront tant qu’ils sont cohérents et ne gênent pas inutilement vos significations.

Je suis tout à fait d’accord pour inclure le nom de la table dans le nom du champ ID, exactement pour les raisons que vous donnez. En général, il s’agit du seul champ dans lequel je voudrais inclure le nom de la table.

Je déteste le nom d’identification simple. Je préfère fortement utiliser toujours le invoice_id ou une variante de celle-ci. Je sais toujours quelle table est la table faisant autorité pour l’identifiant quand je dois le faire, mais cela m’embrouille

 SELECT * from Invoice inv, InvoiceLine inv_l where inv_l.InvoiceID = inv.ID SELECT * from Invoice inv, InvoiceLine inv_l where inv_l.ID = inv.InvoiceLineID SELECT * from Invoice inv, InvoiceLine inv_l where inv_l.ID = inv.InvoiceID SELECT * from Invoice inv, InvoiceLine inv_l where inv_l.InvoiceLineID = inv.ID 

Le pire de tous est le mélange que vous mentionnez, totalement déroutant. J’ai dû travailler avec une firebase database où c’était presque toujours foo_id, sauf dans l’un des identifiants les plus utilisés. C’était l’enfer total.

Je préfère DomainName || ‘ID’ (ie NomDomaine + ID)

DomainName est souvent, mais pas toujours, identique à TableName.

Le problème avec l’ID tout seul est qu’il ne s’agrandit pas. Une fois que vous avez environ 200 tables, chacune avec une première colonne nommée ID, les données commencent à se ressembler. Si vous qualifiez toujours l’ID avec le nom de la table, cela aide un peu, mais pas beaucoup.

DomainName & ID peut être utilisé pour nommer des clés étrangères ainsi que des clés primaires. Lorsque les clés étrangères portent le nom de la colonne qu’elles référencent, cela peut être une aide mnémonique. Formellement, lier le nom d’une clé étrangère à la clé à laquelle il fait référence n’est pas nécessaire, puisque la contrainte d’intégrité référentielle établira la référence. Mais c’est très pratique quand il s’agit de lire des requêtes et des mises à jour.

Parfois, DomainName || ‘ID’ ne peut pas être utilisé, car il y aurait deux colonnes dans la même table avec le même nom. Exemple: Employees.EmployeeID et Employees.SupervisorID. Dans ces cas, j’utilise RoleName || “ID”, comme dans l’exemple.

Enfin, j’utilise des clés naturelles plutôt que des clés synthétiques lorsque cela est possible. Il existe des situations où les clés naturelles sont indisponibles ou indignes de confiance, mais il existe de nombreuses situations où la clé naturelle est le bon choix. Dans ces cas, je laisse la clé naturelle prendre le nom qu’elle aurait naturellement. Ce nom n’a souvent même pas les lettres «ID». Exemple: OrderNo où No est une abréviation de “Number”.

Pour chaque tableau, je choisis un raccourci de lettre d’arbre (par exemple, Employees => Emp)

De cette façon, une clé primaire numérique automatique devient nkEmp .

C’est court, unique dans toute la firebase database et je connais exactement ses propriétés en un coup d’œil.

Je garde les mêmes noms en SQL et toutes les langues que j’utilise (principalement C #, Javascript, VB6).

Voir les conventions de dénomination du site Interakt pour un système bien pensé de nommage des tables et des colonnes. La méthode utilise un suffixe pour chaque table ( _prd pour une table de produit ou _ctg pour une table de catégorie) et l’ajoute à chaque colonne d’une table donnée. Ainsi, la colonne d’identité de la table de produits serait id_prd et est donc unique dans la firebase database.

Ils vont un peu plus loin pour aider à comprendre les clés étrangères: La clé étrangère dans la table de produit qui fait référence à la table de catégorie serait idctg_prd sorte qu’il est évident à quelle table elle appartient (suffixe _prd ) et à quelle table elle se réfère ( Catégorie).

Les avantages sont qu’il n’y a pas d’ambiguïté avec les colonnes d’identité dans les différentes tables, et que vous pouvez voir en un coup d’œil les colonnes auxquelles une requête fait référence par les noms de colonne.

voir aussi la convention de dénomination Clé primaire / Clé étrangère

Vous pouvez utiliser la convention de dénomination suivante. Il a ses défauts mais il résout vos problèmes particuliers.

1. Utilisez des pseudonymes courts (3 à 4 caractères) pour les noms de tables, par exemple Invoice – inv , InvoiceLines – invl
2. Nommez les colonnes de la table en utilisant ces pseudonymes, à savoir inv_id , invl_id
3. Pour les références, les colonnes utilisent invl_inv_id pour les noms.

de cette façon, vous pourriez dire

 SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id