Conventions de dénomination des bases de données, tables et colonnes? [fermé]

791

Chaque fois que je crée une base de données, je me demande toujours s'il existe une meilleure façon de nommer un élément dans ma base de données. Très souvent, je me pose les questions suivantes:

  1. Les noms de table doivent-ils être pluriels?
  2. Les noms de colonne doivent-ils être singuliers?
  3. Dois-je préfixer des tables ou des colonnes?
  4. Dois-je utiliser n'importe quel cas pour nommer les articles?

Existe-t-il des recommandations pour nommer les éléments d'une base de données?

GateKiller
la source
7
Je pense que nous devrions nommer le pluriel pour les tableaux et le singulier pour les colonnes.
AZ_
7
Je vois une table comme "stockage" avec plusieurs éléments, pas une seule "entité", donc je la nomme au pluriel. Lorsque je mappais des tableaux en objets, je nommais les objets au singulier. Ceci est juste mon opinion personnelle.
dpp
2
@Tryinko Utiliser ID partout est VIVANT EN ENFER pour quiconque fait des jointures de plusieurs tables. Il n'y a aucun moyen possible que le léger avantage de savoir que c'est le PK l'emporte sur l'incroyable agacement de recréer la colonne d'identification Dang dans chaque requête sanglante encore et encore. Si vous voulez un moyen de désigner PK dans un tableau, faites-en la première colonne. En outre, dénoter les FK dans les noms des colonnes est dans mon esprit un autre anti-modèle solidement diabolique.
ErikE
2
Jetez un œil à cette réponse .
PerformanceDBA

Réponses:

315

Je recommande de consulter les exemples de bases de données SQL Server de Microsoft: https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

L'exemple AdventureWorks utilise une convention de dénomination très claire et cohérente qui utilise des noms de schéma pour l'organisation des objets de base de données.

  1. Noms singuliers pour les tables
  2. Noms singuliers pour les colonnes
  3. Nom de schéma pour le préfixe des tables (ex: SchemeName.TableName)
  4. Boîtier Pascal (alias boîtier camel supérieur)
urini
la source
14
wilsonmar.com/sql_adventureworks.htm est une excellente analyse du schéma AdventureWorks.
Daniel Trebbien
209
Je ne compterais sur Microsoft pour aucune norme - si vous regardez leur base de données Northwind, vous verrez qu'ils utilisent des tables plurielles, des noms de colonnes singulières, des préfixes de schéma pour les tables, des préfixes de table pour les colonnes de clé primaire, des préfixes de contrainte hongrois et pire de tous les ESPACES "" pour les noms de table de plusieurs mots. De plus, les tables système pour SQLServer utilisent des pluriels, il semble donc que AdventureWorks était le mouton noir de ce groupe.
Marcus Pope
63
Je pense que le principal problème ici est que la foule de noms de tables singulières semble considérer la table comme l'entité, plutôt que la ligne de la table que la foule plurielle fait. Vous devez vous demander de quoi il s'agit. Si la table n'est qu'un conteneur de lignes, n'est-il pas plus logique d'utiliser une dénomination plurielle? Vous ne nommeriez jamais une collection au code au singulier, alors pourquoi nommeriez-vous la table au singulier? Pourquoi l'incohérence? J'entends tous les arguments sur la façon dont ils sont triés et utilisés dans les jointures, mais tous ces arguments semblent très fragiles. Si tout se résume à la préférence, j'irai avec la cohérence et pluraliserai.
Jason
4
Considérez également dans quelle direction va la marée. Il semble que cela va dans le sens des noms de table pluriels, d'autant plus que toutes les tables système dans SQL Server sont toutes plurielles, et la valeur par défaut pour Entity Framework est plurielle dès le départ. Si c'est la position de Microsoft, je veux aller dans la direction où nous serons dans 20 ans. Même les conventions de base de données d'Oracle disent plusieurs noms de table. Pensez simplement au nombre de développeurs c # qui détestaient le mot-clé "var" lors de son introduction, qui est désormais le moyen largement accepté de définir les variables.
Jason
7
@Jasmine - Je vois votre point de vue, bien que je pense que vous avez nommé par inadvertance votre exemple de table à l'envers. "TableOfInvoices" devrait être raccourci en "Invoices", ce que je préfère. Au lieu de cela, vous vouliez probablement dire «InvoiceTable», ce qui est logique pour raccourcir «Invoice».
Derek
281

Réponse tardive ici, mais en bref:

  1. Ma préférence est plurielle
  2. Oui
  3. Tableaux : * Habituellement * aucun préfixe n'est préférable. Colonnes : Non.
  4. Tables et colonnes: PascalCase.

Élaboration:

(1) Ce que vous devez faire. Il y a très peu de choses que vous devez faire d'une certaine manière, à chaque fois, mais il y en a quelques-unes.

  • Nommez vos clés primaires au format "[singularOfTableName] ID". Autrement dit, que votre nom de table soit Client ou Clients , la clé primaire doit être CustomerID .
  • En outre, les clés étrangères doivent être nommées de manière cohérente dans différentes tables. Il devrait être légal de battre quelqu'un qui ne le fait pas. Je dirais que si les contraintes de clé étrangère définies sont souvent importantes, la dénomination de clé étrangère cohérente est toujours importante
  • Votre base de données doit avoir des conventions internes . Même si dans les sections plus tard vous me verrez être très flexible, au sein d' une dénomination de base de données doit être très cohérente. Que votre table pour les clients s'appelle Clients ou Client est moins important que de le faire de la même manière dans la même base de données. Et vous pouvez lancer une pièce pour déterminer comment utiliser les traits de soulignement, mais vous devez ensuite continuer à les utiliser de la même manière . Si vous ne le faites pas, vous êtes une mauvaise personne qui devrait avoir une faible estime de soi.

(2) Ce que vous devriez probablement faire.

  • Les champs représentant le même type de données sur différentes tables doivent être nommés de la même manière. N'ayez pas Zip sur une table et ZipCode sur une autre.
  • Pour séparer les mots de vos noms de table ou de colonne, utilisez PascalCasing. L'utilisation de camelCasing ne serait pas intrinsèquement problématique, mais ce n'est pas la convention et cela aurait l'air drôle. Je répondrai aux soulignements dans un instant. (Vous ne pouvez pas utiliser ALLCAPS comme autrefois. OBNOXIOUSTABLE.ANNOYING_COLUMN était correct dans DB2 il y a 20 ans, mais pas maintenant.)
  • Ne raccourcissez ni n'abrégez artificiellement les mots. Il vaut mieux qu'un nom soit long et clair que court et déroutant. Les noms ultra-courts sont un souvenir des temps plus sombres et plus sauvages. Cus_AddRef. Qu'est-ce que c'est que ça? Référence du destinataire de la garde? Remboursement supplémentaire client? Référence d'adresse personnalisée?

(3) Ce que vous devriez considérer.

  • Je pense vraiment que vous devriez avoir plusieurs noms pour les tableaux; certains pensent singulier. Lisez les arguments ailleurs. Les noms de colonnes doivent cependant être singuliers. Même si vous utilisez plusieurs noms de table, les tables qui représentent des combinaisons d'autres tables peuvent être au singulier. Par exemple, si vous avez des promotions et des articles table table , une table représentant un article faisant partie d'une promotion pourrait être Promotions_Items, mais elle pourrait aussi légitimement être Promotion_Items je pense (reflétant la relation un-à-plusieurs).
  • Utilisez les soulignements de manière cohérente et dans un but particulier. Seuls les noms de tables générales doivent être suffisamment clairs avec PascalCasing; vous n'avez pas besoin de soulignements pour séparer les mots. Enregistrer souligne soit (a) pour indiquer une table associative ou (b) pour le préfixe, que j'aborderai dans la puce suivante.
  • Le préfixe n'est ni bon ni mauvais. Ce n'est généralement pas le meilleur. Dans votre première ou deux premières bases de données, je ne suggérerais pas d'utiliser des préfixes pour le regroupement thématique général des tableaux. Les tableaux ne correspondent pas facilement à vos catégories, et il peut en fait être plus difficile de trouver des tableaux. Avec l'expérience, vous pouvez planifier et appliquer un schéma de préfixe qui fait plus de bien que de mal. J'ai travaillé dans une base de données une fois où les tables de données ont commencé par tbl , les tables de configuration avec ctbl , les vues avec vew , proc's sp et udf's fnet quelques autres; il a été méticuleusement appliqué de manière cohérente, donc ça a bien marché. La seule fois où vous AVEZ BESOIN de préfixes, c'est lorsque vous avez des solutions vraiment distinctes qui, pour une raison quelconque, résident dans la même base de données; les préfixer peut être très utile pour regrouper les tableaux. Le préfixe est également correct pour des situations spéciales, comme pour les tables temporaires que vous souhaitez mettre en évidence.
  • Très rarement (voire jamais) voudriez-vous préfixer des colonnes.
Patrick Karcher
la source
11
"Les champs représentant le même type de données sur différentes tables doivent être nommés de la même manière. Ne pas avoir Zip sur une table et ZipCode sur une autre." Oui oui un million de fois oui. Pouvez-vous dire que notre base de données n'a pas été conçue de cette façon? Un personid peut être référencé d'une douzaine de façons différentes, très ennuyeux à entretenir. J'ai toujours respecté cette règle dans toutes les bases de données sur lesquelles je contrôlais la conception et cela rend la vie beaucoup plus simple.
HLGEM
87
Je pense que la clé primaire devrait simplement être "ID". Une telle convention simple rend la clé primaire prévisible et rapidement identifiable. Je préfère cependant ajouter le nom de la table ("PersonID") lorsqu'il est utilisé comme clé étrangère dans d'autres tables. Cette convention pourrait aider à faire la distinction entre une clé primaire et des clés étrangères dans la même table.
Triynko du
55
@Tryinko Utiliser ID partout est VIVANT EN ENFER pour quiconque fait des jointures de plusieurs tables. Il n'y a aucun moyen que le léger avantage de savoir qu'il s'agit du PK l'emporte sur l'incroyable agacement de recréer la colonne d'identification Dang dans chaque sanglante requête encore et encore. Si vous voulez un moyen de désigner PK dans un tableau, faites-en la première colonne. En outre, dénoter les FK dans les noms des colonnes est dans mon esprit un autre anti-modèle solidement diabolique.
ErikE
18
@Triynko si vous utilisez uniquement "ID", il devient également impossible par programme de déterminer la table à laquelle il appartient. Avec le préfixe du nom de table, vous pouvez simplement couper les deux derniers chiffres d'une clé primaire et connaître le nom de la table à laquelle il appartient via le code. Souvent, les informaticiens et les administrateurs de bases de données ne réalisent pas qu'il existe des avantages de codage pour les programmeurs dans la conception de bases de données de certaines manières.
dallin
16
@ErikE Je veux dire que vous ne savez pas s'il CustomerIDs'agit de la clé primaire de la Customertable ou d'une clé étrangère dans une autre table. C'est un problème mineur. Pourquoi voudriez-vous utiliser des noms pauvres comme c? CustomerID = Customer.IDest très clair en ce que vous voyez que vous joignez une clé étrangère avec une clé primaire; ce n'est pas redondant car les deux côtés sont deux choses différentes. L'attribution d'un nom à un seul caractère est une mauvaise pratique de l'OMI.
Dave Cousineau
100

D'accord, puisque nous pesons avec l'opinion:

Je pense que les noms de table doivent être pluriels. Les tables sont une collection (une table) d'entités. Chaque ligne représente une seule entité et le tableau représente la collection. J'appellerais donc un tableau des entités Personne Personnes (ou Personnes, selon ce qui vous plait).

Pour ceux qui aiment voir des "noms d'entité" singuliers dans les requêtes, c'est pour cela que j'utiliserais des alias de table pour:

SELECT person.Name
FROM People person

Un peu comme LINQ "from person in people select person.Name".

Quant aux 2, 3 et 4, je suis d'accord avec @Lars.

Matt Hamilton
la source
17
@Emtucifor: En anglais, nous ne disons pas "Regardez toutes les personnes dans cette foule de personnes!" Il faut s'attendre à avoir un problème conceptuel avec des choses multiples auxquelles un mot singulier fait référence. Ce n'est ni normal ni approprié. Les «données» sont exceptionnelles et sont souvent utilisées pour désigner un morceau d'un volume de substance, un peu comme un «gâteau». "Voudriez-vous (un morceau de) gâteau?" Nommer un tableau "People" car il contient des informations sur plusieurs individus est beaucoup plus logique que de le nommer "Person". Une classe de données nommée "Person" pour la ROW est logique, tout comme les noms de colonnes singulières.
Triynko
6
@Emtucifor: En fin de compte, tout langage est arbitraire et conventionnel. Je faisais juste valoir que, classiquement, nous désignons une collection d'articles comme le pluriel du type d'article qui s'y trouve. Ainsi, une collection de lignes où chaque ligne contient des informations sur une seule personne serait désignée comme une collection de personnes. Mais si vous voulez vous y référer comme une collection de personnes, allez-y.
Triynko
3
@Emtucifor: Oui, lol. Nommer la table "PersonCollection" équivaudrait à la nommer "People". Comparez cela avec le fait de nommer une telle collection juste "Personne", ce qui n'a pas de sens :)
Triynko
4
@Emtucifor: Alors, pensons-y sous un autre angle pour mettre la convention de dénomination dans un contexte. Supposons que vous ayez des classes d'objets pour représenter à la fois la ligne et la table. "Personne" a évidemment du sens pour la classe qui représente une ligne de données. Si votre table a également été nommée "Personne", vous risquez d'avoir un conflit de dénomination ou une certaine confusion. Je pense simplement qu'il est plus logique de nommer des objets avec une pluralité précise. Une ligne contenant des données sur une personne doit s'appeler Personne, et un tableau contenant des informations sur des personnes ou plusieurs personnes s'appelle Personnes, Collection de personnes, Personnes, etc.
Triynko
5
@Josh M. Eh bien, pas dans les deux sens. Si vous suivez mon chemin, vous pouvez alias la table People en tant que "personne" et avoir SELECT person.Name. Problème résolu. ;-)
Matt Hamilton
73

Je travaille dans une équipe de support de base de données avec trois DBA et nos options envisagées sont:

  1. Toute norme de dénomination est préférable à aucune norme.
  2. Il n'y a pas de "vrai" standard, nous avons tous nos préférences
  3. S'il existe déjà une norme, utilisez-la. Ne créez pas une autre norme ou ne brouillez pas les normes existantes.

Nous utilisons des noms singuliers pour les tableaux. Les tableaux ont tendance à être préfixés avec le nom du système (ou son acronyme). Ceci est utile si le système est complexe car vous pouvez modifier le préfixe pour regrouper les tables de manière logique (par exemple reg_customer, reg_booking et regadmin_limits).

Pour les champs, nous nous attendons à ce que les noms de champ incluent le préfixe / acryonme de la table (c'est-à-dire cust_address1) et nous préférons également l'utilisation d'un ensemble standard de suffixes (_id pour le PK, _cd pour "code", _nm pour "nom ", _nb pour" numéro ", _dt pour" Date ").

Le nom du champ de clé Foriegn doit être le même que celui du champ Clé primaire.

c'est à dire

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

Lors du développement d'un nouveau projet, je vous recommande d'écrire tous les noms d'entité, préfixes et acronymes préférés et de donner ce document à vos développeurs. Ensuite, lorsqu'ils décident de créer une nouvelle table, ils peuvent se référer au document plutôt que de "deviner" comment la table et les champs doivent être appelés.

Gars
la source
9
Surtout pour le numéro 3, nous avons eu un groupe de gens qui ont tous été embauchés dans la même entreprise et ils ont essayé d'imposer leur ancienne norme de dénomination (qu'aucun d'entre nous n'utilisait) à tout ce qu'ils faisaient. Très ennuyant.
HLGEM
40
Rend certainement le SQL illisible; mais je pense que je peux traduire. cust_nm doit être CustomerName , booking_dt doit être BookingDate . reg_customer, eh bien je n'ai aucune idée de ce que c'est.
Ian Boyd
3
@Ian. L'intention est de vous en tenir à la convension de dénomination à laquelle vous étiez habitué et de la garder cohérente. JE SAIS TOUJOURS que tout champ de date est _dt, tout champ de nom est _nm. 'reg' est un exemple de système "d'enregistrement" (réservations, clients, etc.) et toutes les tables associées auraient le même préfixe. Mais chacun à sa façon ...
Guy
7
je conviens qu'une norme particulière n'est pas aussi importante que d'avoir une norme cohérente. Mais certaines normes sont erronées. DB2 et noms de colonnes comme CSPTCN, CSPTLN, CSPTMN, CSDLN. Les gens devraient apprendre que les noms longs ont été inventés - nous pouvons nous permettre de rendre les choses lisibles.
Ian Boyd
17
Au fil des années, j'ai ajouté de nouvelles colonnes à la fin de mes tableaux dans l'application que j'ai développée et commercialisée. Parfois, j'utilise des noms anglais dans mes colonnes, parfois j'utilise l'espagnol et parfois je réutilise des colonnes pour autre chose, au lieu de les supprimer et d'ajouter une nouvelle colonne avec un nom descriptif approprié pour ce qu'elle est utilisée. J'ai délibérément fait cela afin d'OBFUSQUER mon code source au cas où quelqu'un d'autre essaierait de pirater ou de désosser mon code. Seulement je peux le comprendre, quelqu'un d'autre sera frustré! .. De cette façon, ils doivent toujours compter sur moi pour quoi que ce soit!
Frank R.
47
  1. Non. Une table doit être nommée d'après l'entité qu'elle représente. Personne, et non personne, c'est la façon dont vous vous référez à la personne que l'un des enregistrements représente.
  2. Encore une fois, même chose. La colonne FirstName ne doit vraiment pas s'appeler FirstNames. Tout dépend de ce que vous voulez représenter avec la colonne.
  3. NON.
  4. Oui. Cassez-le pour plus de clarté. Si vous avez besoin de colonnes comme "FirstName", la casse facilitera la lecture.

D'accord. C'est mon 0,02 $

Lars Mæhlum
la source
5
Ajoutant une certaine clarté au numéro 3 - les préfixes sont un moyen d'incorporer des métadonnées dans le nom de la colonne. Il ne devrait pas être nécessaire de le faire dans n'importe quelle base de données moderne pour les mêmes raisons que (la surutilisation de) la notation hongroise.
Mark McDonald
21
`sélectionner le top 15 de la commande 'ou' sélectionner le top 15 de la commande '? Ce dernier est ma préférence (humaine).
Ian Boyd
8
@Ian Boyd: Yep: SELECT TOP 100 * FROM Report R INNER JOIN VisitReport VR ON R.ReportID = VR.ReportID. Tout dépend de la façon dont vous en pensez. Si vous mettez une image d'un citron sur une boîte métallique, vous sauriez qu'il y avait des citrons à l'intérieur, sans avoir besoin de deux citrons à l'extérieur pour indiquer qu'il pourrait être pluriel. Bien sûr, vous pourriez l'étiqueter avec le mot écrit "citrons". Mais cela pourrait tout aussi bien être "citron". Pour acquérir la ressource nommée "citron", rendez-vous ici.
ErikE
6
ajoutez 0,01 $ pour utiliser UpperCase dans les noms de colonne et ajoutez 0,01 $ pour utiliser le soulignement dans les noms de colonne afin qu'il soit plus facile de distinguer les noms de colonne à la vue. Total = mon don de 0,02 $ à vous!
Frank R.
6
"Une table doit être nommée d'après l'entité qu'elle représente" Une table est une collection d'entités. Alors qu'une table est aussi une entité, c'est une entité de type "Table" qu'il est inutile d'ajouter à son nom.
Trisped
34

Je suis également en faveur d'une convention de dénomination de style ISO / IEC 11179, notant qu'il s'agit de lignes directrices plutôt que d'être normatives.

Voir Nom de l'élément de données sur Wikipédia :

"Les tables sont des collections d'entités et suivent les directives de dénomination de la collection. Idéalement, un nom collectif est utilisé: par exemple, Personnel. Le pluriel est également correct: Employés. Les noms incorrects incluent: Employé, tblEmployee et EmployeeTable."

Comme toujours, il existe des exceptions aux règles, par exemple une table qui a toujours exactement une ligne peut être meilleure avec un nom singulier, par exemple une table de configuration. Et la cohérence est de la plus haute importance: vérifiez si votre boutique a une convention et, si oui, respectez-la; si vous ne l'aimez pas, faites une analyse de rentabilisation pour la faire changer plutôt que d'être le seul garde forestier.

un jour
la source
-1: Le texte référencé n'a rien à voir avec ISO / IEC 11179. La page wikipedia référencée ne doit pas être approuvée; lire la norme actuelle à la place ( metadata-standards.org/11179/#A5 )
mkadunc
@onedaywhen: Je ne connais pas assez le sujet pour corriger la page wikipedia; De plus, la page wikipedia n'est pas tellement erronée qu'elle est trompeuse - elle ne dit pas explicitement que l'ISO / CEI 11179 inclut les conventions de dénomination de la base de données, elle dit simplement que "ISO / CEI 11179 s'applique lorsque vous nommez des tables et des colonnes dans un base de données relationnelle ". Il fournit ensuite un exemple de conventions de dénomination qui pourraient être utilisées pour la base de données relationnelle. Cela vous laisse penser que l'exemple est quelque chose tiré de la norme, alors que c'est vraiment quelque chose inventé par l'auteur de l'article de wikipedia.
mkadunc
27

J'entends constamment l'argument selon lequel la pluralisation ou non d'une table est une question de goût personnel et il n'y a pas de meilleure pratique. Je ne crois pas que ce soit vrai, surtout en tant que programmeur par opposition à un DBA. Pour autant que je sache, il n'y a aucune raison légitime de pluraliser un nom de table autre que "Cela a du sens pour moi car c'est une collection d'objets", alors qu'il y a des gains légitimes dans le code en ayant des noms de table singuliers. Par exemple:

  1. Il évite les bugs et les erreurs causés par plusieurs ambiguïtés. Les programmeurs ne sont pas exactement connus pour leur expertise en orthographe, et la pluralisation de certains mots est source de confusion. Par exemple, le pluriel se termine-t-il par «es» ou simplement «s»? S'agit-il de personnes ou de personnes? Lorsque vous travaillez sur un projet avec de grandes équipes, cela peut devenir un problème. Par exemple, une instance où un membre de l'équipe utilise la méthode incorrecte pour pluraliser une table qu'il crée. Au moment où j'interagis avec cette table, elle est utilisée partout dans le code auquel je n'ai pas accès ou que je mettrais trop de temps à corriger. Le résultat est que je dois me rappeler de mal orthographier la table chaque fois que je l'utilise. Quelque chose de très similaire à cela m'est arrivé. Plus il est facile pour chaque membre de l'équipe d'utiliser de manière cohérente et simple les informations exactes, corriger les noms de table sans erreurs ou avoir à rechercher constamment des noms de table, mieux c'est. La version singulière est beaucoup plus facile à gérer dans un environnement d'équipe.

  2. Si vous utilisez la version singulière d'un nom de table ET le préfixe de la clé primaire avec le nom de la table, vous avez maintenant l'avantage de déterminer facilement un nom de table à partir d'une clé primaire ou vice versa via le code seul. Vous pouvez recevoir une variable avec un nom de table, concaténer "Id" à la fin, et vous avez maintenant la clé primaire de la table via le code, sans avoir à faire de requête supplémentaire. Ou vous pouvez couper "Id" à la fin d'une clé primaire pour déterminer un nom de table via le code. Si vous utilisez "id" sans nom de table pour la clé primaire, vous ne pouvez pas via le code déterminer le nom de la table à partir de la clé primaire. De plus, la plupart des personnes qui pluralisent les noms de table et préfixent les colonnes PK avec le nom de table utilisent la version singulière du nom de table dans le PK (par exemple les statuts et status_id),

  3. Si vous rendez les noms de table singuliers, vous pouvez les faire correspondre aux noms de classe qu'ils représentent. Encore une fois, cela peut simplifier le code et vous permettre de faire des choses vraiment intéressantes, comme instancier une classe en n'ayant rien d'autre que le nom de la table. Cela rend également votre code plus cohérent, ce qui conduit à ...

  4. Si vous rendez le nom de la table singulier, cela rend votre schéma de dénomination cohérent, organisé et facile à maintenir dans chaque emplacement. Vous savez que dans chaque instance de votre code, que ce soit dans un nom de colonne, comme nom de classe ou comme nom de table, c'est le même nom exact. Cela vous permet de faire des recherches globales pour voir partout où les données sont utilisées. Lorsque vous pluralisez un nom de table, il y aura des cas où vous utiliserez la version singulière de ce nom de table (la classe dans laquelle il se transforme, dans la clé primaire). Il est tout simplement logique de ne pas avoir de cas où vos données sont appelées plurielles et certains cas singulières.

Pour résumer, si vous pluralisez les noms de vos tables, vous perdez toutes sortes d'avantages pour rendre votre code plus intelligent et plus facile à manipuler. Il peut même y avoir des cas où vous devez avoir des tables / tableaux de recherche pour convertir vos noms de table en objets ou en codes locaux que vous auriez pu éviter. Les noms de table singuliers, bien que se sentant peut-être un peu bizarres au début, offrent des avantages significatifs par rapport aux noms pluralisés et je pense que c'est la meilleure pratique.

dallin
la source
26

notre préférence:

  1. Les noms de table doivent-ils être pluriels?
    Jamais. Les arguments pour qu'il s'agisse d'une collection ont du sens, mais vous ne savez jamais ce que la table va contenir (0,1 ou plusieurs éléments). Les règles plurielles compliquent inutilement la dénomination. 1 maison, 2 maisons, souris vs souris, personne vs personnes, et nous n'avons même pas regardé d'autres langues.

    Update person set property = 'value'agit sur chaque personne dans le tableau.
    Select * from person where person.name = 'Greg'renvoie une collection / un ensemble de lignes de lignes de personne.

  2. Les noms de colonne doivent-ils être singuliers?
    Habituellement, oui, sauf lorsque vous enfreignez les règles de normalisation.

  3. Dois-je préfixer des tables ou des colonnes?
    Surtout une préférence de plateforme. Nous préférons préfixer les colonnes avec le nom de la table. Nous ne préfixons pas les tables, mais nous faisons des vues de préfixe (v_) et des procédures stockées (sp_ ou f_ (fonction)). Cela aide les personnes qui souhaitent essayer upday v_person.age qui est en fait un champ calculé dans une vue (qui ne peut pas être mis à jour de toute façon).

    C'est aussi un excellent moyen d'éviter la collision de mots clés (delivery.from se casse, mais delivery_from ne le fait pas).

    Cela rend le code plus verbeux, mais facilite souvent la lisibilité.

    bob = new person()
    bob.person_name = 'Bob'
    bob.person_dob = '1958-12-21'
    ... est très lisible et explicite. Cela peut cependant devenir incontrôlable:

    customer.customer_customer_type_id

    indique une relation entre le client et la table customer_type, indique la clé primaire de la table customer_type (customer_type_id) et si jamais vous voyez 'customer_customer_type_id' lors du débogage d'une requête, vous savez instantanément d'où elle vient (table client).

    ou lorsque vous avez une relation MM entre type_client et catégorie_client (seuls certains types sont disponibles pour certaines catégories)

    customer_category_customer_type_id

    ... est un peu (!) sur le côté long.

  4. Dois-je utiliser n'importe quel cas pour nommer les articles? Oui - en minuscules :), avec des traits de soulignement. Ce sont très lisibles et multi-plateformes. Avec 3 ci-dessus, il est également logique.

    La plupart d'entre eux sont cependant des préférences. - Tant que vous êtes cohérent, il doit être prévisible pour quiconque doit le lire.

Albert
la source
1
SELECT * FROM people AS person WHERE person.name = 'Greg'sonne le plus naturel pour moi.
Kenmore
1
@Zuko Généralement, la convention de dénomination pour la clé primaire de table est <table name><id>, par exemple PersonIDou Person_IDetc. Par conséquent, il est plus logique de ne PAS nommer vos tables au pluriel car chaque enregistrement est une personne distincte et non des personnes.
M. Blond
15

Je sais que c'est tard dans le jeu, et la question a déjà été très bien répondu, mais je veux donner mon avis sur # 3 concernant le préfixe des noms de colonne.

Toutes les colonnes doivent être nommées avec un préfixe unique à la table dans laquelle elles sont définies.

Par exemple, étant donné les tableaux "client" et "adresse", allons-y avec les préfixes de "cust" et "addr", respectivement. "client" aurait "cust_id", "cust_name", etc. dedans. "adresse" aurait "addr_id", "addr_cust_id" (FK retour au client), "addr_street", etc. dedans.

Lorsque j'ai été présenté pour la première fois avec cette norme, j'étais complètement opposé à cela; Je détestais l'idée. Je ne pouvais pas supporter l'idée de toute cette frappe et redondance supplémentaires. Maintenant, j'ai assez d'expérience avec ça pour ne plus jamais y retourner.

Le résultat de cette opération est que toutes les colonnes de votre schéma de base de données sont uniques. Il y a un avantage majeur à cela, qui l'emporte sur tous les arguments contre (à mon avis, bien sûr):

Vous pouvez rechercher l'ensemble de votre base de code et trouver de manière fiable chaque ligne de code qui touche une colonne particulière.

L'avantage du n ° 1 est incroyablement énorme. Je peux déprécier une colonne et savoir exactement quels fichiers doivent être mis à jour avant que la colonne puisse être supprimée du schéma en toute sécurité. Je peux changer la signification d'une colonne et savoir exactement quel code doit être refactorisé. Ou je peux simplement dire si les données d'une colonne sont même utilisées dans une partie particulière du système. Je ne peux pas compter le nombre de fois où cela a transformé un projet potentiellement énorme en un projet simple, ni le nombre d'heures que nous avons économisées dans le travail de développement.

Un autre avantage relativement mineur est que vous ne devez utiliser des alias de table que lorsque vous effectuez une auto-jointure:

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';
Granger
la source
1
Ensuite, vous ne pouvez plus reliably find every line of code that touches a particular column... N'est-ce pas le but?
raveren
6
@Raveren - Vous pouvez toujours. Si tout ce que vous faites est "SELECT *", alors la requête n'est pas pertinente à cet effet. Quand / Si plus tard, vous utilisez les résultats de cette requête, vous devez utiliser le nom de la colonne pour faire quelque chose avec ses données, c'est donc l'endroit dont vous devez vous soucier dans votre code, pas l'instruction SQL.
Granger
Je serais curieux de savoir quelles situations nécessitent SELECT *? Je ne voudrais certainement pas que quiconque utilise cela dans le code de production. Oui, il est utile pour les requêtes ad hoc et pour découvrir quel élément de données rend les résultats de votre requête de jointure multiple bizarres, mais je ne peux penser à aucun endroit dans le code de production où cela est nécessaire.
HLGEM
2
À moins que vous ne codiez l'ensemble de votre application dans un langage non OO, le fait d'avoir une couche ORM décente rend cet argument redondant.
Adam
6
Donc, en raison de cette réponse, j'ai décidé d'essayer d'utiliser des préfixes de table sur un grand projet et j'ai pensé que je ferais rapport. Cela a rendu les tables de refactorisation extrêmement faciles, ce qui était génial! Cependant, ce fut une douleur plus grande que je ne l'avais prévu. Notre base de données contenait de nombreuses tables nommées complexes. Il est facile de se rappeler que Cust est le préfixe du client, mais pas aussi facile de se souvenir du préfixe de HazardVerificationMethod. Chaque fois que j'écrivais une table ou un champ, je devais faire une pause pour réfléchir au préfixe. En fin de compte, j'ai décidé que la vitesse et la commodité étaient plus importantes que la recherche, mais je pensais que c'était une expérience précieuse.
dallin
15

Mes opinions à ce sujet sont les suivantes:

1) Non, les noms de table doivent être singuliers.

Bien que cela semble logique pour la sélection simple ( select * from Orders), cela a moins de sens pour l'équivalent OO ( Orders x = new Orders).

Une table dans une base de données est vraiment l'ensemble de cette entité, cela a plus de sens une fois que vous utilisez set-logic:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

Cette dernière ligne, la logique réelle de la jointure, semble confuse avec plusieurs noms de table.

Je ne suis pas sûr de toujours utiliser un alias (comme le suggère Matt) clarifie cela.

2) Ils doivent être singuliers car ils ne détiennent qu'une seule propriété

3) Jamais, si le nom de la colonne est ambigu (comme ci-dessus où ils ont tous deux une colonne appelée [Clé]) le nom de la table (ou son alias) peut les distinguer assez bien. Vous voulez que les requêtes soient rapides à saisir et simples - les préfixes ajoutent une complexité inutile.

4) Tout ce que vous voulez, je vous suggère CapitalCase

Je ne pense pas qu'il y ait un ensemble de lignes directrices absolues sur ces points.

Tant que tout ce que vous choisissez est cohérent dans l'application ou la base de données, je ne pense pas que cela soit vraiment important.

Keith
la source
3
Qu'est-ce que c'est que ça CapitalCase?
ViRuSTriNiTé
@ViRuSTriNiTy, il voulait probablement direpascal case
marctrem
Keith, sur le numéro 3, je fais les deux, et je suis incohérent (mais je m'égare), mais je ne comprends pas pourquoi il est mauvais d'avoir un nom de colonne descriptif tant qu'il n'est pas par dessus bord, même avec une table, un variable, etc.
johnny
@johnny ce n'est pas mauvais, en tant que tel, tout simplement pas nécessaire. Pourquoi taper des trucs que vous n'avez pas à faire? Aussi la plupart IntelliSense utilise principalement le début du nom, donc si vous avez Product.ProductName, Product.ProductID, Product.ProductPriceetc taper Product.Pvous donne tous les champs préfixés.
Keith
13

À mon avis:

  1. Les noms de table doivent être pluriels.
  2. Les noms de colonne doivent être singuliers.
  3. Non.
  4. Soit CamelCase (mon préféré) ou underscore_separated pour les noms de table et les noms de colonne.

Cependant, comme cela a été mentionné, toute convention vaut mieux qu’aucune convention. Peu importe comment vous choisissez de le faire, documentez-le afin que les modifications futures respectent les mêmes conventions.

Thomas Owens
la source
1
concernant # 4, PascalCase ... camelCase ... snake_case ...
Andrew
11

Je pense que la meilleure réponse à chacune de ces questions serait donnée par vous et votre équipe. Il est beaucoup plus important d'avoir une convention de dénomination que son exactitude.

Comme il n'y a pas de bonne réponse à cela, vous devriez prendre un certain temps (mais pas trop) et choisir vos propres conventions et - voici la partie importante - respectez-la.

Bien sûr, il est bon de chercher des informations sur les normes à ce sujet, c'est ce que vous demandez, mais ne vous inquiétez pas ou ne vous inquiétez pas du nombre de réponses différentes que vous pourriez obtenir: choisissez celle qui vous semble la meilleure.

Au cas où, voici mes réponses:

  1. Oui. Une table est un groupe d' enregistrements , d' enseignants ou d' acteurs , donc ... pluriel.
  2. Oui.
  3. Je ne les utilise pas.
  4. La base de données que j'utilise le plus souvent - Firebird - garde tout en majuscules, donc peu importe. Quoi qu'il en soit, lorsque je programme, j'écris les noms d'une manière plus facile à lire, comme releaseYear .
Mario Marinato
la source
11
  1. Gardez les noms de table au singulier, personne et non les gens
    1. Pareil ici
    2. Non. J'ai vu de terribles préfixes, allant jusqu'à dire qu'il s'agissait d'une table (tbl_) ou d'une procédure de stockage utilisateur (usp_). Ceci suivi du nom de la base de données ... Ne le faites pas!
    3. Oui. J'ai tendance à PascalCase tous mes noms de table
Cloche
la source
28
OMG. NON. Noms de table DÉFINITIVEMENT pluriel. C'est une COLLECTION. Il contient plusieurs choses. "sélectionnez * parmi PERSONNES". Vous ne sélectionnez pas parmi une seule personne, vous sélectionnez parmi plusieurs PERSONNES!
Triynko
4
J'ai toujours aimé la façon dont l'instruction select sonne mieux si elle est plurielle. SELECT id,name FROM contacts WHERE email_address LIKE '%gmail%'tableaux au pluriel, colonnes au singulier. Toujours une question d'opinion personnelle.
scunliffe
le préfixe tbl, qry, etc. peut être extrêmement utile lorsque vous manipulez des métadonnées de base de données.Si vous examinez l'objet dans une base de données, une convention de dénomination simple et rapide peut accélérer considérablement la compréhension
Cruachan
9

Les conventions de dénomination permettent à l'équipe de développement de concevoir la découvrabilité et la maintenabilité au cœur du projet.

Une bonne convention de nommage prend du temps à évoluer, mais une fois qu'elle est en place, elle permet à l'équipe d'avancer avec un langage commun. Une bonne convention de dénomination se développe naturellement avec le projet. Une bonne convention de dénomination résiste facilement aux changements pendant la phase la plus longue et la plus importante du cycle de vie du logiciel - la gestion des services en production.

Voici mes réponses:

  1. Oui, les noms de table doivent être pluriels lorsqu'ils font référence à un ensemble d' opérations , de titres ou de contreparties par exemple.
  2. Oui.
  3. Oui. Les tables SQL sont préfixées par tb_, les vues sont préfixées vw_, les procédures stockées sont préfixées usp_ et les déclencheurs sont préfixés tg_ suivi du nom de la base de données.
  4. Le nom de la colonne doit être en minuscules séparés par un trait de soulignement.

Le nommage est difficile, mais dans chaque organisation, il y a quelqu'un qui peut nommer les choses et dans chaque équipe logicielle, il devrait y avoir quelqu'un qui prend la responsabilité des normes de nommage et s'assure que les problèmes de nommage comme sec_id , sec_value et security_id sont résolus tôt avant d'être au projet. .

Alors, quels sont les principes de base d'une bonne convention de dénomination et de normes: -

  • Utilisez la langue de votre client et de votre domaine de solution
  • Soyez descriptif
  • Être cohérent
  • Lever l'ambiguïté, réfléchir et refactoriser
  • N'utilisez pas d'abréviations à moins qu'elles ne soient claires pour tout le monde
  • N'utilisez pas de mots clés réservés SQL comme noms de colonne
winsql
la source
3
les tables sont par définition des relations. qui sont en fait singuliers. les préfixes sont nuls. Avez-vous déjà eu besoin de transformer une table en vue ou vice-versa? essayez cela avec des préfixes. quelle différence cela fait-il si c'est une vue ou une table?
William Jones
Le préfixe pourrait aider lorsque nous avons le même nom pour deux objets - fonction et procédure stockée. J'aurais une fonction avec un nom comme «GetApproverList» et avec le même nom, je voudrais créer une procédure stockée qui appellera cette fonction en interne. SQL ne permettra pas la création de deux objets avec le même nom.
Ravinder Singh
7
SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName
Ian Boyd
la source
2
Notez les normes utilisées: les tables contiennent plusieurs éléments, les utilisateurs ont un prénom, les mots-clés T-SQL en majuscules, les définitions des tables en cas Pascal.
Ian Boyd
3
faute de frappe: Lastnamedevrait êtreLastName
aminimalanimal
1
Le nom de la table doit être singulier, c'est-à-dire: utilisateur au lieu d'utilisateurs
AZ_
Et notez comment les noms de table sont pluriels; car ils détiennent des utilisateurs , pas des utilisateurs .
Ian Boyd
5

Les noms de table doivent toujours être singuliers, car ils représentent un ensemble d'objets. Comme vous dites troupeau pour désigner un groupe de moutons, ou troupeau désigne un groupe d'oiseaux. Pas besoin de pluriel. Lorsqu'un nom de table est composé de deux noms et que la convention de dénomination est au pluriel, il devient difficile de savoir si le nom au pluriel doit être le premier mot ou le deuxième mot ou les deux. C'est la logique - Object.instance, pas objects.instance. Ou TableName.column, pas TableNames.column (s). Microsoft SQL n'est pas sensible à la casse, il est plus facile de lire les noms de table, si des lettres majuscules sont utilisées, pour séparer les noms de table ou de colonne lorsqu'ils sont composés de deux ou plusieurs noms.

Annie
la source
2
Un troupeau est un groupe de moutons . A Usern'est pas un groupe d'utilisateurs.
EricRobertBrewer
4

Nom de la table: il doit être singulier, car il s'agit d'une entité singulière représentant un objet du monde réel et non des objets, qui est singulier.

Nom de la colonne: Il ne doit être singulier que s'il transmet qu'il contiendra une valeur atomique et confirmera la théorie de la normalisation. Si toutefois il existe n nombre de propriétés du même type, elles doivent être suffixées de 1, 2, ..., n, etc.

Préfixer les tables / colonnes: c'est un sujet énorme, nous en discuterons plus tard.

Boîtier: il devrait s'agir d'un étui Camel

Mon ami, Patrick Karcher , je vous demande de ne pas écrire quoi que ce soit qui puisse être offensant pour quelqu'un, comme vous l'avez écrit, "• De plus, les clés étrangères doivent être nommées de manière cohérente dans différentes tables. Il devrait être légal de battre quelqu'un qui ne faites cela. ". Je n'ai jamais fait cette erreur mon ami Patrick, mais j'écris généralement. Et s'ils prévoient ensemble de vous battre pour ça? :)

vishesh marwah
la source
2
Vous dites donc que la table est l'entité? Ou la ligne du tableau est-elle l'entité? Pour moi, une table est une collection de lignes - donc une collection d'entités qui implique le pluriel.
Jason
4

Très tard pour la fête mais je voulais quand même ajouter mes deux cents sur les préfixes de colonne

Il semble y avoir deux arguments principaux pour utiliser la norme de dénomination table_column (ou tableColumn) pour les colonnes, toutes deux basées sur le fait que le nom de la colonne lui-même sera unique dans l'ensemble de votre base de données:

1) Vous n'avez pas à spécifier à tout moment les noms de table et / ou les alias de colonne dans vos requêtes

2) Vous pouvez facilement rechercher tout le code pour le nom de la colonne

Je pense que les deux arguments sont viciés. La solution aux deux problèmes sans utiliser de préfixes est facile. Voici ma proposition:

Utilisez toujours le nom de la table dans votre SQL. Par exemple, utilisez toujours table.column au lieu de column.

Cela résout évidemment 2) car vous pouvez maintenant simplement rechercher table.column au lieu de table_column.

Mais je peux vous entendre crier, comment ça résout 1)? Il s'agissait exactement d'éviter cela. Oui, c'était vrai, mais la solution était horriblement défectueuse. Pourquoi? Eh bien, la solution de préfixe se résume à:
Pour éviter d'avoir à spécifier table.column en cas d'ambiguïté, vous nommez toutes vos colonnes table_column!
Mais cela signifie que vous devrez désormais TOUJOURS écrire le nom de la colonne chaque fois que vous spécifiez une colonne. Mais si vous devez le faire de toute façon, quel est l'avantage par rapport à l'écriture toujours explicite de table.column? Exactement, il n'y a aucun avantage, c'est exactement le même nombre de caractères à taper.

edit: oui, je suis conscient que le fait de nommer les colonnes avec le préfixe renforce l'utilisation correcte alors que mon approche repose sur les programmeurs

janb
la source
1
Comme vous l'avez mentionné, vous ne pouvez pas compter sur chaque cas ayant table.column. Les programmeurs oublieront en un seul endroit, puis votre recherche et remplacement globale vient de casser tout votre programme. Ou vous en ferez une règle et quelqu'un pensera qu'il remplit la règle en utilisant un alias de la table, déjouant ainsi une recherche globale. De plus, si vous souhaitez organiser votre code en ayant une sorte de classe de base de données (ce que tout bon programmeur fera), il y aura des moments où vous passerez simplement un nom de colonne à une fonction db ou aurez simplement le nom de colonne seul dans une variable.
dallin
2
@janb: Je soutiens totalement votre réponse. Je veux également ajouter que l'utilisation de la recherche de texte pour trouver des dépendances est une manière barbare de naviguer dans le code. Une fois que les gens se seront débarrassés de cette pratique de recherche barbare - ils commenceront à utiliser un bon nom, qui est table.column. Donc, le problème n'est pas le style de nommage, le problème est de mauvais outils conçus pour les barbares.
alpav
Votre argument est erroné. Le problème est que cela fonctionne dans les deux sens et n'ajoute aucun avantage. Vous dites, pour résoudre ce problème, écrivez toujours toujours table.column, puisque vous écrivez déjà table_column. Eh bien, vous pouvez également dire simplement écrire table_colonne parce que vous écrivez déjà table.colonne. En d'autres termes, il n'y a aucune différence entre votre réponse, sauf qu'elle introduit des erreurs possibles et n'applique pas les conventions. C'est la raison pour laquelle nous avons un mot-clé «privé». Nous pourrions faire confiance aux programmeurs pour toujours utiliser correctement les variables de classe, mais le mot-clé les applique et élimine les erreurs possibles.
dallin
3

Conventions de dénomination des bases de données (et style) (cliquez ici pour une description plus détaillée)

les noms de table choisissent des noms courts et sans ambiguïté, en utilisant pas plus d'un ou deux mots, les tables de distinction facilitent facilement la dénomination des noms de champ uniques ainsi que la recherche et les tables de liaison donnent aux tables des noms singuliers, jamais pluriels (mise à jour: je suis toujours d'accord avec les raisons données) pour cette convention, mais la plupart des gens aiment vraiment les noms de table au pluriel, j'ai donc adouci ma position) ... suivez le lien ci-dessus s'il vous plaît

AZ_
la source
1
bien que ce que Oracle suggère qu'il soit totalement opposé de lier le lien ci-dessus. découvrez ce que dit Oracle ici. ss64.com/ora/syntax-naming.html
AZ_
La convention de dénomination d'Oracle était la plus drôle de toutes .. e.g. PATIENTS would have a primary key called pa_patient_id_pk!!
nawfal
2

Noms de table au singulier. Supposons que vous modélisiez une relation entre une personne et son adresse. Par exemple, si vous lisez un modèle de données, préférez-vous que «chaque personne puisse vivre à 0,1 ou plusieurs adresses». ou "chaque personne peut vivre à 0,1 ou plusieurs adresses". Je pense qu'il est plus facile de pluraliser l'adresse, plutôt que de reformuler les gens en tant que personne. De plus, les noms collectifs sont assez souvent similaires à la version singulière.

paul444
la source
-4

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

Ce sont les conventions qui m'ont été enseignées, mais vous devez vous adapter à tout ce que vous utilisez pour développer vos tuyaux.

  1. Pluriel. C'est une collection d'entités.
  2. Oui. L'attribut est une représentation de la propriété singulière d'une entité.
  3. Oui, le nom de table de préfixe permet de nommer facilement tous les index de contraintes et les alias de table.
  4. Cas Pascal pour les noms de table et de colonne, préfixe + toutes les majuscules pour les index et les contraintes.
Lord Future
la source
6
ChristianName ... c'est une convention étrange.
BobbyShaftoe
3
Des numéros de série sur vos tables? Est -ce que quelqu'un pense sérieusement que cela fait sens des œuvres pour les développeurs?
ErikE
Depuis que cet exemple l'a soulevé ... Je suis personnellement contre la mise en majuscule des acronymes dans les noms de table ou de colonne, car je pense que cela rend la lecture plus difficile. Donc, dans ce cas, je dirais que StudentId est préférable à StudentID. Ce n'est pas grave lorsque l'acronyme est à la fin, mais j'ai vu d'innombrables exemples dans mon travail où les acronymes étaient au début ou au milieu du nom, et cela a rendu plus difficile à analyser dans votre esprit. Ex: StudentABCSSN vs StudentAbcSsn.
redOctober13