Table relationnelle convention de nommage

Question

Je commence un nouveau projet et que vous souhaitez mettre à ma table et les noms de colonne de droite dès le début. Par exemple, j'ai toujours utilisé au pluriel dans les noms de table, mais a appris récemment le singulier est correct.

Donc, si j'ai une table "utilisateur" et ensuite j'ai reçu les produits que seul l'utilisateur aura, si le tableau est nommé "user_product" ou tout simplement "produit" ? C'est un "un à plusieurs" de la relation.

Et plus loin, si j'aurais (pour certaines raisons) plusieurs descriptions de produits pour chaque produit, serait-il "user_product_description" ou "product_description" ou tout simplement "description"? Bien sûr, avec le droit de clés étrangères.. Nommant seulement la description serait difficile, parce que je pourrais aussi avoir la description de l'utilisateur ou de la description du compte ou que ce soit..

Mais si je veux un pur table relationnelle (plusieurs à plusieurs) avec seulement deux colonnes, quel serait-il ressembler? "user_stuff" ou peut-être quelque chose comme "rel_user_stuff" ? Et si la première, ce qui permettrait de distinguer ce à partir de, par exemple "user_product"?

Toute aide est grandement appréciée et si il y a une sorte de convention de nommage standard que vous les gars recommander, n'hésitez pas à le lien.

Merci

Answer 1

récemment appris singulier est correct

Correct. Le pluriel du nom est un signe sûr de quelqu'un qui n'a pas lu tout les matériaux standard. Utilisons le singulier et le pluriel naturellement, dans la langue, comme dans:

Each Customer has zero-to-many SalesOrders.

La bonne chose à propos de la Norme est, ils sont tous intégrés les uns avec les autres, ils travaillent ensemble; et ils ont été écrits par des esprits plus grande que la nôtre, donc nous n'avons pas à débattre. Le nom de table standard se réfère à chaque ligne dans la table, qui est utilisé dans l'ensemble du verbiage (encore une fois, c'est pourquoi le singulier est correcte et le pluriel est pour les gens qui n'ont pas entendu parler de la norme); et non pas la totalité du contenu de la table (qui, nous le savons: Customer contient tous les Clients); la norme de définition de Relations est

Each Customer has zero-to-many Products

pas Customers have zero-to-many Products.

Donc, si j'ai une table "utilisateur" et ensuite j'ai reçu les produits que seul l'utilisateur devra, si le tableau est nommé "utilisateur-produit" ou "produits" ? C'est un "un à plusieurs" de la relation.

Ce n'est pas un nom de convention de question, c'est une db question de conception. Il n'a pas d'importance si user::product 1::n. Ce qui importe est de savoir si l' product est une entité distincte, et si elle est Indépendante, c'est à dire. il peut exister sur son propre. Par conséquent, product, pas user_product. Et si product n'existe que dans le contexte d'un user, c'est à dire. il est Dépendant, alors user_product.

Et plus loin, si j'aurais (pour certaines raisons) plusieurs descriptions de produits pour chaque produit, serait-il de "l'utilisateur-product-description" ou "produit-description" ou tout simplement "description"? Bien sûr, avec le droit de clés étrangères.. Nommant seulement la description serait difficile, parce que je pourrais aussi avoir la description de l'utilisateur ou de compte de description ou de quoi que ce soit.

C'est le droit. Soit user_product_description xor product_description sera correct, basé sur la ci-dessus. Ce n'est pas pour le différencier des autres _descriptions,

Mais si je veux un pur table relationnelle (plusieurs à plusieurs) avec seulement deux colonnes, quel serait-il ressembler? "utilisateur-stuff" ou peut-être quelque chose comme "rel-utilisateur-trucs" ? Et si la première, ce qui permettrait de distinguer ce à partir de, par exemple "utilisateur-produit"?

1. Espérons que toutes les tables dans la base de données relationnelle sont de la pure relationnelle normalisée tables. Il n'est pas nécessaire d'identifier que dans le nom (sinon, toutes les tables seront rel_something).

2. S'il contient uniquement les Clés primaires des deux parents (ce qui résout la logique n::n relation qui n'existe pas comme une table au niveau logique, dans une table physique (oui, niveau physique), qui est un Tableau Associatif, . Oui, généralement, le nom est une combinaison des deux parents, les noms de table.

   • Si ce n'est pas un Tableau Associatif (en plus des deux PKs, il contient des données), puis le nom approprié.
     .
3. Si vous vous retrouvez avec deux user_product tables, alors que c'est un très fort signal que vous n'avez pas normalisé les données. Afin de revenir à quelques pas de le faire, et le nom des tables de manière précise et cohérente. Les noms seront alors de résoudre eux-mêmes.

---

Toute aide est grandement appréciée et si il y a une sorte de convention de nommage standard que vous les gars recommander, n'hésitez pas à le lien.

Ce que vous faites est très important, et il aura une incidence sur la facilité d'utilisation et la compréhension à tous les niveaux. Donc il est bon pour obtenir la compréhension autant que possible dès le départ. La pertinence de la plupart de ce ne sera pas clair jusqu'à ce que vous commencer à coder en SQL.

1. Maintenir des données, et non d'une application ou d'utilisation de l'accent. Il est, après tout 2011, et les bases de données sont censés être indépendants des applications qui les utilisent. De cette façon, à mesure qu'ils grandissent, et plus qu'une application utilise, le nom qui restera de sens, et n'ont besoin d'aucune correction. (Bases de données qui sont complètement intégrés dans une seule application ne sont pas des bases de données.) Nom les éléments de données comme les données, seulement.

2. Être très attentif, et le nom des tables et des colonnes de façon très précise. Ne pas utiliser UpdatedDate si c'est un type de données DATETIME, ou _description si elle contient de la posologie.

3. Il est important d'être cohérent dans la base de données. Ne pas utiliser NumProduct en un même lieu pour indiquer le nombre de Produits et d' ItemNo ou ItemNumdans un autre endroit pour indiquer le nombre d'Éléments. Utiliser NumSomething pour les nombres, et SomethingNo pour les identificateurs, de manière cohérente.

4. Ne faites pas précéder le nom de la colonne avec un nom de table ou de code court, comme user_first_name. SQL prévoit déjà le nom de la table comme un qualificatif: user.first_name.

   • la première exception est pour les PKs. Toujours utiliser user_id, jamais id.
   • et toujours utiliser le même nom partout où PK est transporté en tant que FK. Par conséquent, user_product aura un user_id comme une composante de son PK.

   • la pertinence de ce sera clair quand vous commencer à coder.

   • la deuxième exception est lorsqu'il n'y a plus d'un FK référence à la même table parent de la table, dans l'enfant. Utiliser des Noms de Rôle afin de différencier le sens ou l'utilisation, par exemple, AssemblyId et ComponentId au lieu de ProductId. Et dans ce cas, ne pas utiliser l'indifférencié ProductId pour l'un d'entre eux. Être précis.

5. Préfixe Où vous avez plus de 100 tableaux, préfixe de la table des noms de Domaine: REF_ pour la Référence; OE_ pour l'Entrée des commandes, etc. Seulement au niveau physique, pas de la logique (il encombre le modèle).

6. Suffixe. Je ne suis pas d'utiliser les suffixes-la sur des tables, et j'ai toujours utiliser des suffixes sur tout le reste. Avec un trait de soulignement. Cela signifie que dans la logique de l'utilisation normale de la base de données, il n'y a aucun des caractères de soulignement; mais sur le plan administratif, des traits de soulignement sont utilisés comme séparateur:

   _V Vue (avec les principales TableName à l'avant, bien sûr)
   _fk Clé étrangère (le nom de la contrainte, et non pas le nom de la colonne) formulaire simple
   _cac Cache
   _seg Segment
   Etc

   Ce qui est vraiment important parce que quand le serveur vous donne un message d'erreur:

   Foreign key violation on Customer_SalesOrder_fk

   vous savez exactement ce qui FK a été violé. L' Parent_Child_fk vs Child_Parent_fk est parce que (a) il s'affiche dans l'ordre de tri correct lorsque vous êtes à la recherche pour eux et (b) nous savons toujours l'enfant concerné, ce que nous sommes deviner à l'est, lequel des deux Parents.

7. Les Clés étrangères (la contrainte, pas de la colonne). Le minimum est identifié ci-dessus. Le meilleur nom pour un FK est d'utiliser le VerbPhrase, ce qui élimine la nécessité d'un suffixe. Mais c'est seulement pour les haut de gamme de bases de données relationnelles, où les tables sont matures, et la VerbPhrases ont été identifiés:

   Customer_Initiates_SalesOrder

   Vendor_Offers_PartVendor

   Le message d'erreur est juste délicieux:

   Foreign key violation on Vendor_Offers_PartVendor.

8. Les Indices sont des particuliers, de sorte qu'ils ont une convention de nommage de leur très propre, constitué de, dans l'ordre:
   U Unique
   C Cluster
   _ séparateur
   Si une colonne ou très peu de colonnes, puis le
   ColumnNames

   Si plus de quelques colonnes, puis
   PK Clé primaire (selon modèle)
   AK Autre Clé (IDEF1X terme)
   Etc

   Ainsi, lorsque UC_CustomerId ou Product_AK s'affiche un message d'erreur, il me dit quelque chose de significatif; quand je regarde les indices sur une table, je peut les différencier facilement.

9. Trouver quelqu'un de qualifié et professionnel et de les suivre. Regarder leurs dessins, et d'étudier les conventions de nommage qu'ils utilisent. Poser des questions précises sur ce que vous ne comprenez pas. À l'inverse, courir comme un diable de quelqu'un qui fait preuve de peu de respect pour les conventions de nommage et de normes. Voici quelques-uns pour vous aider à démarrer

   • Ils contiennent des exemples réels de tous les ci-dessus. Poser des questions re de nommage des questions dans ce thread.
   • Bien sûr, les modèles de mise en œuvre de plusieurs autres Normes, au-delà des conventions de nommage; vous pouvez ignorer ces pour le moment, ou n'hésitez pas à poser des nouvelles questions.
   • Ils sont plusieurs pages chacun, et les images ne chargent pas de façon cohérente sur les différents navigateurs; de sorte que vous aurez à cliquer sur les liens.
   • Notez que les fichiers PDF ont de navigation complète, donc cliquez sur le bleu des boutons de verre, ou les objets où l'expansion est identifié:
   • Les lecteurs qui ne sont pas familiers avec la structure Relationnelle de la Modélisation Standard peut trouver le IDEF1X Notation utile.

L'Entrée des commandes Et des Stocks avec conforme à la Norme Adresses

Simple inter-office Bulletin système PHP/MySQL

Surveillance du capteur avec plein Temporelle de la capacité de

Answer 2

Singulier vs Pluriel: Choisissez-en un et de rester avec elle.

Les colonnes ne devrait pas être le préfixe/suffixe/infixés ou d'une façon fixe avec des références au fait que c'est une colonne. Il en va de même pour les tables. Ne pas le nom de tables EMPLOYEE_T ou TBL_EMPLOYEES parce que le second, elle est remplacée par une vue, les choses deviennent vraiment déroutant.

Ne pas incorporer des informations de type dans les noms, tels que "vc_firstname" pour varchar, ou "flavour_enum". Aussi, ne pas intégrer les contraintes dans la colonne des noms, tels que "department_fk" ou "employee_pk".

En fait, la seule bonne chose à propos de *corrections que je pense, c'est que vous pouvez utiliser des mots réservés, comme where_t, tbl_order, user_vw. Bien sûr, dans ces exemples, l'utilisation du pluriel aurait résolu le problème :)

Ne pas le nom de toutes les clés "ID". Les clés se référant à la même chose, devrait avoir le même nom dans toutes les tables. La colonne id d'utilisateur peut être appelé USER_ID dans la table utilisateur et toutes les tables de référencement de l'utilisateur. La seule fois où il est renommé est lorsque les différents utilisateurs sont à jouer différents rôles, tels que les Message(sender_user_id, receiver_user_id). - Ce vraiment de l'aide lorsque vous traitez avec des requêtes plus.

À Propos De L'Affaire:

thisiswhatithinkofalllowercapscolumnnames.

ALLUPPERCAPSISNOTBETTERBECAUSEITFEELSLIKESOMEONEISSCREAMINGATME.

CamelCaseIsMarginallyBetterButItStillTakesTimeToParse.    

i_recommend_sticking_with_lower_case_and_underscore

En général, il vaut mieux le nom de "tables de mappage" pour correspondre à la relation qu'elle décrit plutôt que les noms des tables de référence. Un utilisateur peut disposer d'un certain nombre de relations de produits: user_likes_product, user_bought_product, user_wants_to_by_product.

Answer 3

Il n'y a pas de "corriger" le sujet singulier vs pluriel -, c'est surtout une question de goût.

Il dépend en partie de votre foyer. Si vous pensez de la table comme une unité, il est titulaire d' 'pluriel' (car il contient de nombreuses lignes - si un nom au pluriel est le cas). Si vous pensez à le nom de la table que l'identification d'une ligne dans une table, vous pourrez préfèrent le "singulière". Cela signifie que votre SQL sera considéré comme travail sur une ligne de la table. C'est OK, mais il est généralement une explication simpliste; SQL fonctionne sur des ensembles (plus ou moins). Cependant, nous pouvons aller avec le singulier pour les réponses à cette question.

1. Puisque vous aurez probablement besoin d'une table "utilisateur", un autre "produit", et la troisième pour connecter des utilisateurs à des produits, alors vous avez besoin d'un tableau 'user_product'.

2. Depuis la description s'applique à un produit, vous pouvez utiliser 'product_description'. À moins que chaque utilisateur les noms de chaque produit pour eux-mêmes...

3. Le " user_product table est (ou pourrait être) un exemple d'une table avec l'ID d'un produit et d'un ID utilisateur et pas grand chose d'autre. Vous nommez les deux tables d'attributs en général, de la même façon: 'user_stuff'. Décoratif préfixes comme "rel_" ne vous aidera pas vraiment. Vous allez voir quelques personnes à l'aide de la " t_ " en face de chaque nom de table, par exemple. Ce n'est pas beaucoup d'aide.

Answer 4

Les pluriels ne sont pas mauvais, aussi longtemps qu'ils sont utilisés de manière cohérente - mais le singulier est ma préférence.

Je voudrais passer avec des traits de soulignement, sauf si vous souhaitez décrire un plusieurs-à-plusieurs relations; et l'utilisation d'un capital initial, car il permet de distinguer les choses dans Orm.

Mais il existe de nombreuses conventions de nommage, donc si vous souhaitez utiliser des caractères de soulignement c'est OK aussi longtemps que sa fait toujours.

Donc:

User

UserProduct (it is a users products after all)

Si un seul utilisateur peut avoir n'importe quel produit puis

UserProductDescription

Mais si le produit est partagé par les utilisateurs:

ProductDescription

Si vous enregistrez votre soulignent plusieurs-à-plusieurs liens vous pouvez faire quelque chose comme:

UserProduct_Stuff

pour former une M-à-M entre UserProduct et des Trucs - pas sûr de la question de la nature exacte de la plusieurs-à-plusieurs requise.

Answer 5

Il n'est pas plus correct d'utiliser au singulier qu'au pluriel, où avez-vous entendu parler? Je dirais plutôt que le pluriel est plus commun que le nommage des tables de base de données...et à mon avis aussi plus logique. Le tableau le plus souvent contenir plus d'une ligne ;) Dans un modèle conceptuel bien que les noms de ces entités sont souvent au singulier.

Sujet de votre question, si le "Produit" et "ProductDescription" sont des concepts avec une identité (par exemple, les entités) dans votre modèle, je voudrais simplement appeler les tables de "Produits" et "ProductDescriptions'. Pour les tables qui sont utilisées afin de mettre en œuvre un plusieurs-à-plusieurs relations que j'ai le plus souvent utiliser la convention de nommage "SideA2SideB", par exemple "Student2Course".