Question Base de données, conventions de dénomination de table et de colonne? [fermé]


Chaque fois que je conçois une base de données, je me demande toujours s'il existe un meilleur moyen de nommer un élément dans ma base de données. Assez souvent, je me pose les questions suivantes:

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

Existe-t-il des directives recommandées pour nommer les éléments dans une base de données?


631
2017-08-11 10:27


origine


Réponses:


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 du schéma pour le préfixe des tables (par exemple: SchemeName.TableName)
  4. Boîtier en Pascal (a.k.a. Boîtier supérieur en chameau)

245
2017-08-11 12:39



Réponse tardive ici, mais en un mot:

  1. ma préférence est pluriel
  2. Oui
  3. les tables: * Habituellement * pas de préfixes est le meilleur. Colonnes: Non.
  4. Les deux tables et colonnes: PascalCase.

Élaboration:

(1) Ce que tu dois faire  Il y a très peu de choses que vous doit faire un certain chemin, à chaque fois, mais il y en a quelques-uns.

  • Nommez votre clés primaires en utilisant le format "[singularOfTableName] ID". Autrement dit, si votre nom de table est Client ou Les clients, la clé primaire devrait être N ° de client.
  • Plus loin, clés étrangères doit être nommé de manière cohérente dans différentes tables. Il devrait être légal de battre quelqu'un qui ne le fait pas. Je soumets que, bien que les contraintes de clé étrangère définies sont souvent important, la dénomination de clé étrangère cohérente est toujours important
  • Votre base de données doit avoir conventions internes. Même si dans les sections suivantes, vous verrez que je suis très flexible, dans un nom de base de données doit être très cohérent. Que votre table pour les clients s'appelle Les 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 retourner une pièce de monnaie pour déterminer comment utiliser les traits de soulignement, mais alors vous doit 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 tu devrais probablement faire.

  • Champs représentant le même type de données sur différentes tables devrait être nommé le même. Ne pas avoir Zip sur une table et ZipCode sur une autre.
  • Pour séparer les mots dans les noms de vos tables ou colonnes, utilisez PascalCasing. Utiliser camelCasing ne serait pas intrinsèquement problématique, mais ce n'est pas la convention et ça aurait l'air marrant. Je vais aborder les traits de soulignement 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 pas raccourcir ou abréger artificiellement les mots. Il vaut mieux qu'un nom soit long et clair que court et déroutant. Les noms ultra-courts sont une survivance des temps plus sombres et plus sauvages. Cus_AddRef. Que diable est-ce? Custodial Addressee Référence? Remboursement additionnel du 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 tables; certains pensent singulier. Lire les arguments ailleurs. Les noms de colonne devraient être singuliers cependant. Même si vous utilisez plusieurs noms de tables, les tables qui représentent des combinaisons d'autres tables peuvent être au singulier. Par exemple, si vous avez un Promotions Et un Articles table, un tableau représentant un élément faisant partie d'une promotion pourrait être Promotions_Items, mais il pourrait aussi être légitimement Promotion_Items je pense (reflétant la relation one-to-many).
  • Utilisez des underscores de manière cohérente et dans un but particulier. Les noms des tables générales doivent être assez clairs avec PascalCasing; vous n'avez pas besoin de traits de soulignement pour séparer les mots. Sauvez les underscores soit (a) pour indiquer une table associative ou (b) pour le préfixage, que je vais aborder dans la puce suivante.
  • Le préfixage n'est ni bon ni mauvais. Il d'habitude n'est pas le meilleur. Dans votre premier db ou deux, je ne suggérerais pas d'utiliser des préfixes pour le groupement thématique général des tables. Les tables finissent par ne pas s'adapter à vos catégories facilement, et il peut réellement le faire Plus fort pour trouver des tables. Avec l'expérience, vous pouvez planifier et appliquer un schéma de préfixation qui fait plus de bien que de mal. J'ai travaillé dans un DB une fois où les tables de données ont commencé avec tbl, tables de configuration avec ctbl, vues avec vew, proc sp, et UDF fnet quelques autres il a été méticuleusement appliqué de manière cohérente, de sorte que tout s'est bien passé. La seule fois où vous avez besoin de préfixes est lorsque vous avez des solutions vraiment séparées qui, pour une raison quelconque, résident dans le même DB; les préfixer peut être très utile pour grouper les tables. Le préfixage convient également aux situations spéciales, comme pour les tables temporaires que vous souhaitez mettre en évidence.
  • Très rarement (si jamais) voudriez-vous pour préfixer les colonnes.

215
2018-01-22 16:07



Ok, puisque nous pesons avec opinion:

Je crois que les noms de table devraient être pluriels. Les tables sont une collection (une table) d'entités. Chaque ligne représente une entité unique et la table représente la collection. Donc j'appellerais une table d'entités Personelles Personnes (ou Personnes, tout ce qui vous plaît).

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

SELECT person.Name
FROM People person

Un peu comme LINQ "de la personne dans les gens sélectionnez la personne.Nom".

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


87
2017-08-11 10:49



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

  1. Toute norme de nommage est mieux que pas de norme.
  2. Il n'y a pas de norme "un vrai", nous avons tous nos préférences
  3. Si la norme existe déjà, utilisez-la. Ne créez pas un autre standard ou ne limitez pas les normes existantes.

Nous utilisons des noms singuliers pour les tableaux. Les tables tendent à être préfixées 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 logiquement (par exemple, reg_customer, reg_booking et regadmin_limits).

Pour les champs, nous nous attendons à ce que les noms de champs incluent le préfixe / acryonm de la table (ie cust_address1) et nous préférons l'utilisation d'un ensemble standard de suffixes (_id pour le PK, _cd pour "code", _nm pour "name ", _nb pour" nombre ", _dt pour" Date ").

Le nom du champ 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és, 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" ce que la table et les champs doivent être appelés.


67
2017-08-11 12:24



  1. Non. Une table doit être nommée d'après l'entité qu'elle représente. La personne, pas les personnes, est la façon dont vous vous référez à qui représente l'un des dossiers.
  2. Encore une fois, même chose. La colonne FirstName ne devrait pas vraiment s'appeler FirstNames. Tout dépend de ce que vous voulez représenter avec la colonne.
  3. NON.
  4. Oui. Cas pour plus de clarté. Si vous avez besoin d'avoir des colonnes comme "FirstName", le cadrage le rendra plus facile à lire.

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


43
2017-08-11 10:35



Je suis également favorable à une convention de dénomination de style ISO / CEI 11179, notant qu'il s'agit de lignes directrices plutôt que d'être prescriptives.

Voir Nom de l'élément de données sur Wikipedia:

"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 ex. une table qui a toujours exactement une rangée peut être meilleure avec un nom singulier, par ex. une table de configuration. Et la cohérence est de la plus haute importance: vérifiez si vous magasinez a une convention et, si oui, suivez-la; Si vous ne l'aimez pas, faites une analyse de rentabilisation pour le faire changer plutôt que d'être le seul rôdeur.


31
2017-10-23 10:45



notre préférence:

  1. Les noms des tables doivent-ils être pluriels?
    Jamais. Les arguments pour que ce soit une collection ont un sens, mais vous ne savez jamais ce que la table va contenir (0,1 ou plusieurs éléments). Les règles plurielles rendent la dénomination inutilement compliquée. 1 maison, 2 maisons, souris contre souris, personne contre personne, et nous n'avons même pas regardé d'autres langues.

    Update person set property = 'value' agit sur chaque personne de la table.
    Select * from person where person.name = 'Greg' retourne une collection / un ensemble de lignes de lignes de personne.

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

  3. Devrais-je préfixer des tables ou des colonnes?
    Surtout une préférence de plate-forme. 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 préfixées (v_) et stored_procedures (sp_ ou f_ (function)). Cela aide les gens qui veulent essayer upday v_person.age qui est en fait un champ calculé dans une vue (qui ne peut pas être UPDATEd de toute façon).

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

    Cela rend le code plus bavard, 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 devenir incontrôlable si:

    customer.customer_customer_type_id

    indique une relation entre le client et la table customer_type, indique la clé primaire sur la table customer_type (customer_type_id) et si vous voyez jamais "customer_customer_type_id" pendant le débogage d'une requête, vous savez instantanément d'où elle provient (table customer).

    ou lorsque vous avez une relation M-M entre customer_type et customer_category (seuls certains types sont disponibles pour certaines catégories)

    customer_category_customer_type_id

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

  4. Devrais-je utiliser n'importe quel cas pour nommer des objets? Oui - minuscule :), avec des traits de soulignement. Ce sont très lisibles et multi-plateforme. Avec 3 ci-dessus, cela a aussi du sens.

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


24
2018-03-26 13:58



Jetez un oeil à la norme ISO 11179-5: Principes de dénomination et d'identification Vous pouvez l'avoir ici: http://metadata-standards.org/11179/#11179-5

J'ai blogué à ce sujet il y a quelques temps: Conventions de dénomination ISO-11179 


19
2017-08-11 13:13



J'entends constamment l'argument selon lequel le fait qu'un tableau soit pluralisé est une question de goût personnel et qu'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. Autant que je sache, il n'y a pas de raisons légitimes de pluriel un nom de table autre que «Cela a du sens pour moi parce que 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ées par des ambiguïtés plurielles. Les programmeurs ne sont pas exactement connus pour leur expertise en orthographe, et la pluralisation de certains mots est déroutante. Par exemple, le mot pluriel se termine-t-il par «es» ou simplement «s»? Est-ce des personnes ou des 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, il est utilisé partout dans le code auquel je n'ai pas accès ou qui prendrait trop de temps pour le réparer. Le résultat est que je dois me souvenir d'épeler la table à chaque fois que je l'utilise. Quelque chose de très similaire à cela m'est arrivé. Plus il est facile pour tous les membres de l'équipe d'utiliser les noms de tables exactes et correctes sans erreurs, ou de chercher constamment des noms de tables, 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 préfixez la clé primaire avec le nom de la table, vous avez maintenant l'avantage de facilement déterminer un nom de table à partir d'une clé primaire ou vice versa via du 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 une requête supplémentaire. Ou vous pouvez couper "Id" de la fin d'une clé primaire pour déterminer un nom de table via le code. Si vous utilisez "id" sans un 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. En outre, la plupart des personnes qui mettent en pluriel les noms de tables et préfixent les colonnes PK avec le nom de la table utilisent la version singulière du nom de la table dans le PK (par exemple statuts et statusId), ce qui rend impossible tout cela.

  3. Si vous créez des noms de table au singulier, 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 bien, 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 table singulier, cela rend votre schéma de nommage cohérent, organisé et facile à maintenir dans chaque endroit. Vous savez que dans chaque instance de votre code, que ce soit dans un nom de colonne, un nom de classe ou un 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 trouve, dans la clé primaire). Il est tout à fait logique de ne pas avoir certains cas où vos données sont désignées comme pluriel et certaines instances au singulier.

Pour résumer, si vous multipliez les noms de vos tables, vous perdrez toutes sortes d'avantages en rendant votre code plus intelligent et plus facile à gérer. Il peut même y avoir des cas où vous devez avoir des tables de recherche / tableaux pour convertir vos noms de table en objets ou des noms de code locaux que vous auriez pu éviter. Les noms de table singuliers, bien que peut-être se sentir un peu bizarre au premier abord, offrent des avantages significatifs par rapport aux noms pluralisés et je crois que c'est la meilleure pratique.


17
2018-04-29 19:26



Je sais que c'est en retard au jeu, et la question a déjà été très bien répondue, mais je veux donner mon avis sur # 3 concernant le préfixage 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 tables "client" et "adresse", allons avec les préfixes de "cust" et "addr", respectivement. "client" aurait "cust_id", "cust_name", etc. "adresse" aurait "addr_id", "addr_cust_id" (FK retour au client), "addr_street", etc.

Quand j'ai été présenté pour la première fois avec cette norme, j'étais contre-attaqué; J'ai détesté l'idée. Je ne pouvais pas supporter l'idée de tout ce type de dactylographie supplémentaire et de redondance. Maintenant, j'en ai assez d'expérience pour ne jamais y retourner.

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

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

Le bénéfice de # 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 la quantité d'heures que nous avons sauvées dans le travail de développement.

Un autre avantage relativement mineur est que vous ne devez utiliser les alias de table que lorsque vous effectuez une jointure automatique:

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%';

14
2017-09-02 22:19