Quelle norme dois-je suivre pour nommer les tables et les vues?

20

Quelle norme dois-je suivre pour nommer les tables et les vues? Par exemple, est-ce une bonne idée de mettre quelque chose comme tbl_ au début des noms de table? Dois-je désigner du code / tables de recherche d'une manière ou d'une autre comme ct_, lut_ ou codes_? Y a-t-il d'autres choses à faire / à ne pas faire?

J'utilise MS SQL Server et j'ai de nombreuses bases de données avec de nombreuses tables, donc ce serait bien d'avoir quelque chose que nous puissions utiliser comme standard avec un support rationnel.

relational-theory naming-convention

— Beth Whitezel
source

29

OK, ne placez JAMAIS la table devant le nom d'une table. C'est une table, nous l'avons déjà maintenant. Cela s'appelle la notation hongroise, et les gens ont cessé de le faire il y a plus de 5 ans.

Appelez simplement l'objet en fonction de ce qu'il est. Si une table contient des données sur les employés, appelez-la "Employé". S'il contient des informations sur les ordinateurs, appelez-le "Ordinateur". S'il fait correspondre des ordinateurs à des employés, appelez-le "EmployeeComputer" ou "ComputerEmployee" (personnellement, j'aime mieux "EmployeeComputer").

Il n'y a pas de véritable convention de dénomination à utiliser (autre que de ne pas utiliser la notation hongroise). Tant que les noms d'objets ont un sens, c'est ce qui est important.

— mrdenny
source

11

En plus de cela, veuillez ne pas mettre les noms des tables sous forme de noms pluriels, comme j'ai vu des exemples d'Employés, de Cumputeurs .. Nous savons tous que les tables sont censées obtenir plusieurs lignes, pas une ..

— Marian

1

Pourquoi voudriez-vous créer des vues d'une table? Tout ce qu'une vue est, c'est une instruction select stockée. Les données ne sont pas matérialisées derrière une vue, sauf si vous utilisez une vue indexée. Je n'utilise pratiquement jamais de vues, jamais. Il n'y a certainement aucun avantage en termes de performances à le faire.

— mrdenny

2

Nous utilisons des vues lorsque nous voulons faire quelque chose comme joindre quelques tables ou traduire des valeurs de code en valeurs lisibles par l'homme. La deuxième situation est celle où vous vous retrouvez avec un nom similaire.

— Beth Whitezel

2

La réponse de M. Denny et les contributeurs suivants sont confirmés

1

@Marian: J'utilise des pluriels car ils rendent les requêtes plus naturelles et résolvent les collisions avec des mots clés. De nombreux systèmes avec lesquels j'ai travaillé ont une entité de commande. L'utilisation de pluriels fait que le nom de la table ordersn'est pas orderet évite d'avoir à citer le nom de la table à chaque fois qu'il s'agit d'utilisateurs. Cela s'applique également aux groupautres mots clés. Heureusement, peu de mots clés entrent en collision avec des entités communes.

— BillThor

13

Nous utilisons des schémas (pensez-y comme des espaces de noms dans SQL peut-être) pour les autorisations et le regroupement. Donc au lieu de "tbl" etc nous avons

Data.Thing
Data.ThingHistory
Data.Stuff

Aucun code ne va dans le schéma de données. Aucune table ne vit en dehors du schéma de données. Bien sûr, cela peut être étendu pour avoir un schéma de recherche ou de transfert si vous le souhaitez.

Pour les vues que nous utilisons, vwmais c'était pour les distinguer des tables dans SQL Server 2000 et c'est un peu hérité maintenant

— gbn
source

3

+1 pour recommander des schémas. Cela vous sera utile tout en conservant une grande base de données avec des centaines de tables. Nous utilisons également des schémas pour le regroupement fonctionnel. Comme dans AdventureWorks db

— CoderHawk

5

Personnellement, je suis un grand fan de la Fanö Bedingung , ce qui signifie ici que pas un nom ne peut être le début d'un autre nom valide.

Et deuxièmement, la distance de Hamming entre deux noms vaut mieux qu'une lettre différente.

Oui, ce sont les règles de l'époque prédigital, mais elles facilitent la vie.

Et les troisièmes noms doivent être prononçables, sinon vous deviendrez fou quand la reconnaissance vocale deviendra vraie.

— bernd_k
source

2

Quand la reconnaissance vocale deviendra vraie, je serai fou de toute façon. :-)

— Beth Whitezel

Seulement si vous soutenez le téléthon

— bernd_k

1

Quand la reconnaissance vocale arrivera, je vais devenir chauffeur de camion. Ça ou un ermite fou.

— mrdenny

Pourriez-vous expliquer plus en détail (peut-être avec un exemple) ce qu'est "Fano Bedingung"?

— Nick Chammas

1

@NickChammas Je pense qu'en anglais, nous appelons ce codage Shannon-Fano .

— Iain Samuel McLean Elder

2

Je ne sais pas qu'il existe vraiment de «meilleure» convention de dénomination, car cela se résume vraiment à la préférence personnelle et à la facilité de développement. Mon conseil est de choisir une convention de dénomination et de la respecter. Si vous souhaitez séparer les mots avec un trait de soulignement, faites-le dans tous vos objets de base de données. Si vous souhaitez utiliser camelCase, faites-le dans tous vos objets de base de données.

Dans ma boutique, nous adhérons aux règles suivantes:

Nous séparons les mots avec des soulignements et utilisons toutes les lettres minuscules.
Nos noms de table décrivent ce qu'ils sont: dbo.person, dbo.invoice.
Nos noms de table plusieurs à plusieurs décrivent également ce qu'ils sont (avec l'ajout de mm pour indiquer qu'une relation plusieurs à plusieurs est mappée: dbo.person_mm_address. Nos procédures stockées définies par l'utilisateur décrivent à la fois l'objet et l'action en cours d'exécution: usp_person_select , usp_address_select_by_city Nos vues et fonctions suivent les mêmes règles que les procédures stockées. Nos index incluent la table, les colonnes clés (dans l'ordre) et une indication de cluster / non-cluster: ix_person_last_name_first_name_nc

Ce n'est pas parce que c'est ce que nous utilisons dans ma boutique que ces règles vous conviennent. Choisissez quelque chose avec lequel votre équipe de développement et vous-même êtes à la fois utile et facile à développer, et établissez une culture de connaissance et d'utilisation de la convention de dénomination que vous décidez. Dans notre cas, cela inclut la révision du code pour tous les objets créés dans une base de données. Au fil du temps, la combinaison d'une convention de dénomination documentée et d'un examen du code par les pairs a conduit à de moins en moins d'écarts par rapport à la convention.

J'espère que cette "non-réponse" aide d'une certaine manière.

— Matt M
source

2

Je suis content de ça depuis des années

noms de table: petites majuscules et tirets bas, singulier {client, produit}
noms de table pour les relations plusieurs à plusieurs: tablename1_tablename2: {customer_product}
vues: petites majuscules ajoutées v à la fin {customerv, productv, product_groupv}
procédures stockées: nom et fonction de la table {customer_select, customer_insert, customer_delete, customer_update}

si vous avez un package d'hébergement partagé bon marché, vous devrez utiliser l'abréviation du projet devant tous vos objets, comme par exemple le site des administrateurs de base de données, da_users, da_questions

— Uğur Gümüşhan
source

Pourquoi product_groupvet non product_group_vpour les vues (si vous insistez sur cette répartition des vues et des tableaux)?

— ypercubeᵀᴹ

@ypercube parce que je suis trop paresseux pour taper un trait de soulignement supplémentaire et que je fais facilement des erreurs de frappe. Je lis les mots plus facilement lorsque j'utilise un trait de soulignement et j'utilise v pour séparer la vue des tableaux, et v n'est pas un mot, donc je n'utilise pas de trait de soulignement. Il semble incohérent, oui, mais je trouve ce format pratique.

— Uğur Gümüşhan