Quelle norme dois-je suivre lors de nommage des tables et des vues?

Question

Quelle norme dois-je suivre lors de nommage des tables et des vues? Par exemple, est-il une bonne idée de mettre quelque chose comme tbl_ au début des noms de table? Dois-je désigner le code / tables de référence d'une certaine façon comme sr_ ct_, lut_ ou codes_? Y at-il / les Don'ts de tout autre faire?

J'utilise MS SQL Server et ont de nombreuses bases de données avec de nombreuses tables de sorte qu'il serait agréable d'avoir quelque chose que nous pouvons utiliser comme standard avec une rationnelle support.

Answer 1

OK, d'abord jamais mis TBL devant le nom d'une table. Il est une table, nous l'avons déjà maintenant. On appelle cela la notation hongroise, et les gens cessé de le faire il y a 5 ans.

Il suffit d'appeler l'objet en fonction de ce qu'il est. Si une table contient des données des employés appellent « employé ». Si elle contient des informations sur les ordinateurs appellent cela « l'ordinateur ». Si elle transforme les ordinateurs aux employés l'appellent « EmployeeComputer » ou « ComputerEmployee » (personnellement je aime « EmployeeComputer » mieux).

Il n'y a pas de véritable convention de nommage droit d'usage (autre que de ne pas utiliser la notation hongroise). Tant que les noms des objets de sens que ce qui est important.

Answer 2

Nous utilisons des schémas (penser comme espaces de noms dans SQL peut-être) pour les autorisations et le regroupement. Ainsi, au lieu de "TBL" etc nous avons

• Data.Thing
• Data.ThingHistory
• Data.Stuff

n ° de code va dans le schéma de données. Aucune table ne vivent en dehors du schéma de données. Cela peut étendre bien sûr d'avoir une recherche ou Staging schéma si vous le souhaitez.

Pour les vues que nous utilisons vw mais ce fut pour les distinguer des tables dans SQL Server 2000 et il est un peu l'héritage maintenant

Answer 3

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

Et la seconde distance de Hamming entre deux noms est mieux plus d'une lettre différente.

Oui, ce sont la règle des temps pré-numérique, mais ils rendent la vie plus facile.

Et troisième noms doivent être prononçable, ou vous est devenu fou, quand la reconnaissance vocale devient vrai.

Answer 4

Je ne sais pas qu'il y ait vraiment une convention de nommage « meilleur » là-bas, comme cela se résume vraiment à vos préférences personnelles et la facilité de développement. Mon conseil est de choisir une convention de nommage et à s'y tenir. Si vous souhaitez des mots séparés par un underscore, faites dans tous vos objets de base de données. Si vous souhaitez utiliser camelCase, faites dans tous vos objets de base de données.

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

Nous séparer les mots avec des underscores et d'utiliser toutes les lettres minuscules.
Nos noms de tables décrivent ce qu'ils sont: dbo.person, dbo.invoice
. Nos nombreux noms à plusieurs tables décrivent également ce qu'ils sont (avec l'ajout de mm pour indiquer une relation plusieurs à plusieurs cartographié: 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 points de vue et les fonctions suivent les mêmes règles que les procédures stockées. Nos indices comprennent le tableau, les colonnes clés (dans l'ordre), et une indication de CLUSTERED / non-cluster: ix_person_last_name_first_name_nc

Tout simplement parce que ce que nous utilisons dans ma boutique, cela ne signifie pas que ces règles sont pour vous. Choisissez quelque chose que vous et votre équipe de développement est à la fois d'accord utile et facile à développer avec, et d'établir une culture de savoir et d'utiliser quelle que soit convention de nommage vous décider. 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'un examen du code de la convention et les pairs nommant documenté a conduit à de moins en moins les écarts par rapport convention.

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

Answer 5

Je suis content de ces années il y a depuis

• noms de table: petites majuscules et underscores, singulier {client, produit}
• noms de table pour beaucoup à de nombreuses relations: tablename1_tablename2: {} customer_product
• Vues: small caps ajoutés v à la fin {customerv, productv, product_groupv}
• procudures stockées: nom de la table et la fonction {customer_select, customer_insert, customer_delete, customer_update}

si vous avez un forfait d'hébergement pas cher mutualisé, vous aurez besoin d'utiliser l'abréviation du projet devant tous vos objets, comme par exemple, les administrateurs de base de données du site, da_users, da_questions