Je démarre un nouveau projet et j'aimerais obtenir mes noms de table et de colonne dès le début. Par exemple, j'ai toujours utilisé le pluriel dans les noms de table, mais le singulier récemment appris est correct.

Donc, si j'ai une table "utilisateur" et que j'ai ensuite des produits que seul l'utilisateur aura, la table doit-elle être nommée "user_product" ou simplement "produit"? C'est une relation un à plusieurs.

Et plus loin, si j'aurais (pour une raison quelconque) plusieurs descriptions de produits pour chaque produit, serait-ce "user_product_description" ou "product_description" ou simplement "description"? Bien sûr, avec le bon jeu de clés étrangères. Ne nommer que la description serait problématique car je pourrais aussi avoir une description d'utilisateur ou une description de compte ou autre.

Et si je veux une table relationnelle pure (plusieurs à plusieurs) avec seulement deux colonnes, à quoi cela ressemblerait-il? "user_stuff" ou peut-être quelque chose comme "rel_user_stuff"? Et si le premier, qu'est-ce qui le distinguerait, par exemple de "user_product"?

Toute aide est très appréciée et s'il existe une sorte de norme de convention de dénomination que vous recommandez, n'hésitez pas à créer un lien.

Merci

Nom de la table

le singulier récemment appris est correct

Oui. Méfiez-vous des païens. Le pluriel dans les noms de table est un signe certain de quelqu'un qui n'a lu aucun des documents standard et n'a aucune connaissance de la théorie des bases de données.

Certaines des choses merveilleuses à propos des normes sont:

• ils sont tous intégrés les uns aux autres
• ils travaillent ensemble
• ils ont été écrits par des esprits plus grands que le nôtre, nous n'avons donc pas à en débattre.

Le nom de table standard fait référence à chaque ligne de la table, qui est utilisée dans tout le verbiage, pas au contenu total de la table (nous savons que la Customertable contient tous les clients).

Relation, phrase verbale

Dans de véritables bases de données relationnelles qui ont été modélisées (par opposition aux systèmes d'archivage d'enregistrements d'avant 1970 [caractérisés par Record IDslesquels sont implémentés dans un conteneur de base de données SQL pour plus de commodité):

• les tables sont les sujets de la base de données, donc ce sont des noms , encore une fois, singuliers
• les relations entre les tables sont les Actions qui ont lieu entre les noms, donc ce sont des verbes (c'est-à-dire qu'ils ne sont pas numérotés ou nommés arbitrairement)
• qui est le prédicat
• tout ce qui peut être lu directement à partir du modèle de données (voir mes exemples à la fin)
• (le prédicat pour une table indépendante (le parent le plus élevé dans une hiérarchie) est qu'elle est indépendante)
• ainsi la phrase verbale est soigneusement choisie, de sorte qu'elle soit la plus significative, et les termes génériques sont évités (cela devient plus facile avec l'expérience). La phrase verbale est importante lors de la modélisation car elle aide à résoudre le modèle, c'est-à-dire. clarifier les relations, identifier les erreurs et corriger les noms de table.

Diagram_A

Bien sûr, la relation est implémentée dans SQL en tant que CONSTRAINT FOREIGN KEYdans la table enfant (plus, plus tard). Voici la phrase verbale (dans le modèle), le prédicat qu'elle représente (à lire à partir du modèle) et le nom de la contrainte FK :

    Initiates
    Each Customer Initiates 0-to-n SalesOrders
    Customer_Initiates_SalesOrder_fk

Tableau • Langue

Cependant, lors de la description du tableau, en particulier dans un langage technique tel que les prédicats, ou toute autre documentation, utilisez le singulier et le pluriel comme ils sont naturellement dans la langue anglaise. En gardant à l'esprit que la table est nommée pour la seule ligne (relation) et la langue se réfère à chaque ligne dérivée (relation dérivée):

    Each Customer initiates zero-to-many SalesOrders

ne pas

    Customers have zero-to-many SalesOrders 

Donc, si j'ai une table "utilisateur" et ensuite j'ai des produits que seul l'utilisateur aura, la table doit-elle être nommée "utilisateur-produit" ou simplement "produit"? C'est une relation un à plusieurs.

(Ce n'est pas une question de convention de dénomination; c'est une question de conception de base de données.) Peu importe si user::productest 1 :: n. Ce qui compte, c'est de savoir s'il products'agit d'une entité distincte et s'il s'agit d'une table indépendante , c'est-à-dire. il peut exister par lui-même. Par conséquent product, non user_product.

Et si productn'existe que dans le contexte d'un user, c'est à dire. il est un tableau à charge , donc user_product.

Diagram_B

Et plus loin, si j'aurais (pour une raison quelconque) plusieurs descriptions de produits pour chaque produit, serait-ce "description-produit-utilisateur" ou "description-produit" ou simplement "description"? Bien sûr, avec le bon jeu de clés étrangères. Nommer uniquement la description serait problématique car je pourrais aussi avoir une description d'utilisateur ou une description de compte ou autre.

C'est vrai. Soit user_product_descriptionxor product_descriptionsera correct, sur la base de ce qui précède. Il ne s'agit pas de le différencier des autres xxxx_descriptions, mais de donner au nom une idée de sa place, le préfixe étant la table parente.

Et si je veux une table relationnelle pure (plusieurs à plusieurs) avec seulement deux colonnes, à quoi cela ressemblerait-il? "user-stuff" ou peut-être quelque chose comme "rel-user-stuff"? Et si le premier, qu'est-ce qui le distinguerait, par exemple de "produit utilisateur"?

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

2. S'il ne contient que les PK des deux parents (ce qui résout la relation logique n :: n qui n'existe pas en tant qu'entité au niveau logique, dans une table physique ), c'est une table associative . Oui, le nom est généralement une combinaison des deux noms de table parent.

   • Notez que dans de tels cas, la phrase verbale s'applique à, et est lue comme, de parent à parent, ignorant la table enfant, car son seul but dans la vie est de relier les deux parents.

     Diagram_C

   • S'il ne s'agit pas d' une table associative (c'est-à-dire qu'en plus des deux PK, elle contient des données), nommez-la de manière appropriée et les phrases verbales s'appliquent à elle, pas au parent à la fin de la relation.

     Diagram_D

3. Si vous vous retrouvez avec deux user_producttables, c'est un signal très fort que vous n'avez pas normalisé les données. Revenez donc quelques étapes en arrière et faites-le, et nommez les tables avec précision et cohérence. Les noms se résoudront alors d'eux-mêmes.

Convention de dénomination

Toute aide est très appréciée et s'il existe une sorte de norme de convention de dénomination que vous recommandez, n'hésitez pas à créer un lien.

Ce que vous faites est très important et cela affectera la facilité d'utilisation et la compréhension à tous les niveaux. Il est donc bon d'avoir le plus de compréhension possible dès le départ. La pertinence de la plupart de ces éléments ne sera pas claire tant que vous ne commencerez pas à coder en SQL.

1. Le cas est le premier élément à traiter. Toutes les majuscules sont inacceptables. Le cas mixte est normal, surtout si les tables sont directement accessibles par les utilisateurs. Reportez-vous mes modèles de données. Notez que lorsque le chercheur utilise un NonSQL démentiel, qui n'a que des minuscules, je le donne, auquel cas j'inclus des traits de soulignement (selon vos exemples).

2. Maintenez un focus sur les données , pas sur une application ou une utilisation. C'est, après tout 2011, que nous avons une architecture ouverte depuis 1984, et les bases de données sont censées être indépendantes des applications qui les utilisent.

   De cette façon, au fur et à mesure qu'ils grandissent et que l'application ne les utilise plus, la dénomination restera significative et ne nécessitera aucune correction. (Les bases de données qui sont complètement intégrées dans une seule application ne sont pas des bases de données.) Nommez les éléments de données uniquement comme des données.

3. Soyez très prévenant et nommez les tables et les colonnes avec beaucoup de précision . Ne pas utiliser UpdatedDates'il s'agit d'un DATETIMEtype de données, utilisez UpdatedDtm. Ne pas utiliser _descriptions'il contient une dose.

4. Il est important d'être cohérent dans toute la base de données. Ne pas utiliser NumProductà un endroit pour indiquer le nombre de produits et / ItemNoou ItemNumà un autre endroit pour indiquer le nombre d'articles. À utiliser NumSomethingpour les nombres et / SomethingNoou SomethingIdpour les identificateurs, de manière cohérente.

5. Ne préfixez pas le nom de la colonne avec un nom de table ou un code court, tel que user_first_name. SQL fournit déjà le nom de la table comme qualificatif:

       table_name.column_name  -- notice the dot
   

6. Des exceptions:

   • La première exception concerne les PK, ils nécessitent un traitement spécial car vous les codez dans des jointures, tout le temps, et vous voulez que les clés se démarquent des colonnes de données. Utilisez toujours user_id, jamais id.

     • Notez que ce n'est pas un nom de table utilisé comme préfixe, mais un nom descriptif approprié pour le composant de la clé: user_idest la colonne qui identifie un utilisateur, pas le idde la usertable.
       • (Sauf bien sûr dans les systèmes d'archivage des enregistrements, où les fichiers sont accessibles par des substituts et il n'y a pas de clés relationnelles, il s'agit là d'une seule et même chose).
     • Utilisez toujours exactement le même nom pour la colonne clé partout où le PK est transporté (migré) en tant que FK.
     • Par conséquent, la user_producttable aura un user_idcomme composant de son PK (user_id, product_no).
     • la pertinence de cela deviendra claire lorsque vous commencerez à coder. Premièrement, avec idde nombreuses tables, il est facile de se mélanger au codage SQL. Deuxièmement, n'importe qui d'autre que le codeur initial n'a aucune idée de ce qu'il essayait de faire. Les deux sont faciles à éviter, si les colonnes clés sont traitées comme ci-dessus.

   • La deuxième exception concerne les cas où plusieurs FK font référence à la même table de table parent, transportés dans l'enfant. Selon le modèle relationnel , utilisez les noms de rôle pour différencier la signification ou l'utilisation, par exemple. AssemblyCodeet ComponentCodepour deux PartCodes. Et dans ce cas, n'utilisez pas l'indifférencié PartCodepour l'un d'entre eux. Être précis.

     Diagram_E

7. Préfixe
   Lorsque vous avez plus de 100 tables, par exemple, préfixez les noms de table avec un domaine:

   REF_pour les tables de référence
   OE_pour le cluster Order Entry, etc.

   Uniquement au niveau physique, pas au niveau logique (cela encombre le modèle).

8. Suffixe
   N'utilisez jamais de suffixes sur les tables et utilisez toujours des suffixes sur tout le reste. Cela signifie que dans l'utilisation logique et normale de la base de données, il n'y a pas de traits de soulignement; mais du côté administratif, les traits de soulignement sont utilisés comme séparateur:

   _VAfficher (avec le principal TableNamedevant, bien sûr)
   _fkClé étrangère (le nom de la contrainte, pas le nom de la colonne) Transaction de segment de
   _caccache (proc ou fonction stockée) Fonction (non transactionnelle), etc.
   _seg
_tr
_fn

   Le format est le nom du tableau ou FK, un trait de soulignement et le nom de l'action, un trait de soulignement et enfin le suffixe.

   Ceci est vraiment important car lorsque le serveur vous donne un message d'erreur:

   ____blah blah blah error on object_name

   vous savez exactement quel objet a été violé et ce qu'il essayait de faire:

   ____blah blah blah error on Customer_Add_tr

9. Clés étrangères (la contrainte, pas la colonne). Le meilleur nom pour un FK est d'utiliser la phrase verbale (moins le «chacun» et la cardinalité).

   Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk

   Utilisez la Parent_Child_fkséquence, ce n'est pas Child_Parent_fkparce que (a) elle apparaît dans le bon ordre de tri lorsque vous les recherchez et (b) nous connaissons toujours l'enfant impliqué, ce que nous devinons est, quel parent. Le message d'erreur est alors ravissant:

   ____ Foreign key violation on Vendor_Offers_PartVendor_fk.

   Cela fonctionne bien pour les personnes qui prennent la peine de modéliser leurs données, là où les phrases verbales ont été identifiées. Pour le reste, les systèmes de classement des enregistrements, etc., utilisent Parent_Child_fk.

10. Les indices sont spéciaux, ils ont donc une convention de dénomination qui leur est propre, composée, dans l'ordre , de chaque position de caractère de 1 à 3:

    UUnique, ou _pour non-unique en
    Ccluster, ou _pour
    _séparateur non en cluster

    Pour le reste:

    • Si la clé est une colonne ou quelques colonnes:
      ____ColumnNames

    • Si la clé comporte plus de quelques colonnes:
      ____ PKClé primaire (selon le modèle)
      ____ AK[*n*]Clé alternative (terme IDEF1X)

    Notez que le nom de la table n'est pas requis dans le nom de l'index, car il apparaît toujours commetable_name.index_name.

    Ainsi, lorsque Customer.UC_CustomerIdou Product.U__AKapparaît dans un message d'erreur, cela vous indique quelque chose de significatif. Lorsque vous regardez les indices sur une table, vous pouvez les différencier facilement.

11. Trouvez une personne qualifiée et professionnelle et suivez-la. Regardez leurs designs et étudiez attentivement les conventions de dénomination qu'ils utilisent. Posez-leur des questions spécifiques sur tout ce que vous ne comprenez pas. Inversement, fuyez comme un enfer quiconque démontre peu de respect pour les conventions de dénomination ou les normes. En voici quelques-unes pour vous aider à démarrer:

    • Ils contiennent des exemples réels de tout ce qui précède. Posez des questions sur la dénomination des questions dans ce fil.
    • Bien entendu, les modèles implémentent plusieurs autres normes, au-delà des conventions de dénomination; vous pouvez soit les ignorer pour le moment, soit poser de nouvelles questions spécifiques .
    • Ce sont plusieurs pages chacune, la prise en charge des images en ligne chez Stack Overflow est pour les oiseaux, et elles ne se chargent pas de manière cohérente sur différents navigateurs; vous devrez donc cliquer sur les liens.
    • Notez que les fichiers PDF ont une navigation complète, cliquez donc sur les boutons en verre bleu ou sur les objets où l'expansion est identifiée:
    • Les lecteurs qui ne sont pas familiarisés avec la norme de modélisation relationnelle peuvent trouver la notation IDEF1X utile.

Saisie des commandes et inventaire avec des adresses conformes aux normes

Système de bulletin inter-bureaux simple pour PHP / MyNonSQL

Surveillance de capteur avec capacité temporelle complète

Réponses aux questions

^{Cela ne peut pas être raisonnablement répondu dans l'espace de commentaire.}

Larry Lustig:
... même l'exemple le plus trivial le montre ...
Si un client a zéro à plusieurs produits et qu'un produit a un à plusieurs composants et qu'un composant a un à plusieurs fournisseurs et qu'un fournisseur n'en vend aucun -à-plusieurs composants et un SalesRep a des clients un-à-plusieurs quels sont les noms «naturels» des tables contenant les clients, les produits, les composants et les fournisseurs?

Il y a deux problèmes majeurs dans votre commentaire:

1. Vous déclarez que votre exemple est "le plus trivial", cependant, il est tout sauf. Avec ce genre de contradiction, je ne sais pas si vous êtes sérieux, si techniquement capable.

2. Cette spéculation «triviale» comporte plusieurs erreurs grossières de normalisation (DB Design).

   • Tant que vous ne les corrigez pas, elles ne sont pas naturelles et anormales, et elles n’ont aucun sens. Vous pouvez aussi bien les nommer anormal_1, anormal_2, etc.

   • Vous avez des «fournisseurs» qui ne fournissent rien; références circulaires (illégales et inutiles); les clients qui achètent des produits sans aucun instrument commercial (tel que Facture ou SalesOrder) comme base pour l'achat (ou les clients "possèdent-ils" des produits?); relations plusieurs-à-plusieurs non résolues; etc.

   • Une fois que cela est normalisé et que les tables requises sont identifiées, leurs noms deviendront évidents. Naturellement.

Dans tous les cas, je vais essayer de répondre à votre requête. Ce qui signifie que je vais devoir y ajouter un peu de sens, ne sachant pas ce que vous vouliez dire, alors veuillez me supporter. Les erreurs grossières sont trop nombreuses pour être énumérées, et étant donné les spécifications de rechange, je ne suis pas sûr de les avoir toutes corrigées.

• Je suppose que si le produit est composé de composants, alors le produit est un assemblage et les composants sont utilisés dans plus d'un assemblage.

• En outre, comme "le fournisseur vend zéro à plusieurs composants", qu'il ne vend pas de produits ou d'assemblages, il ne vend que des composants.

Spéculation vs modèle normalisé

Dans le cas où vous ne le sauriez pas, la différence entre les coins carrés (indépendants) et les coins arrondis (dépendants) est significative, veuillez vous référer au lien Notation IDEF1X. De même les lignes pleines (identifiant) vs les lignes pointillées (non identifiant).

... quels sont les noms «naturels» des tables contenant les clients, les produits, les composants et les fournisseurs?

• Client
• Produit
• Component (Ou, AssemblyComponent, pour ceux qui se rendent compte qu'un fait identifie l'autre)
• Fournisseur

Maintenant que j'ai résolu les tables, je ne comprends pas votre problème. Vous pouvez peut-être poster une question spécifique .

VoteCoffee:
Comment gérez-vous le scénario que Ronnis a posté dans son exemple où plusieurs relations existent entre 2 tables (user_likes_product, user_bought_product)? Je peux mal comprendre, mais cela semble entraîner des noms de table en double en utilisant la convention que vous avez détaillée.

En supposant qu'il n'y a pas d'erreurs de normalisation, User likes Productc'est un prédicat, pas une table. Ne les confondez pas. Reportez-vous à ma réponse, où elle concerne les sujets, les verbes et les prédicats, et ma réponse à Larry immédiatement ci-dessus.

• Chaque tableau contient un ensemble de faits (chaque ligne est un fait). Les prédicats (ou propositions) ne sont pas des faits, ils peuvent ou non être vrais.

  • Le modèle relationnel est basé sur le calcul des prédicats du premier ordre (plus communément appelé logique du premier ordre). Un prédicat est une phrase à clause unique en anglais simple et précis, qui prend la valeur true ou false.

  • En outre, chaque table représente, ou est la mise en œuvre de, de nombreux prédicats, pas un.

• Une requête est un test d'un prédicat (ou d'un certain nombre de prédicats, enchaînés ensemble) qui aboutit à vrai (le fait existe) ou faux (le fait n'existe pas).

• Ainsi, les tables doivent être nommées, comme détaillé dans ma réponse (conventions de dénomination), pour la ligne, le fait et les prédicats doivent être documentés (cela fait certainement partie de la documentation de la base de données), mais comme une liste séparée de prédicats .

• Ce n'est pas une suggestion qu'ils ne sont pas importants. Ils sont très importants, mais je n'écrirai pas cela ici.

• Vite donc. Puisque le modèle relationnel est fondé sur le FOPC, la base de données entière peut être considérée comme un ensemble de déclarations FOPC, un ensemble de prédicats. Mais (a) il existe de nombreux types de prédicats, et (b) une table ne représente pas un seul prédicat (c'est l'implémentation physique de nombreux prédicats et de différents types de prédicats).

• Par conséquent, nommer la table pour "le" prédicat qu'elle "représente" est un concept absurde.

• Les «théoriciens» ne connaissent que quelques Prédicats, ils ne comprennent pas que puisque la RM a été fondée sur la FOL, toute la base de données est un ensemble de Prédicats, et de types différents.

  • Et bien sûr, ils choisissent des absurdes parmi les rares qu'ils connaissent EXISTING_PERSON:; PERSON_IS_CALLED. Si ce n'était pas si triste, ce serait hilarant.

  • Notez également que le nom de la table Standard ou atomique (nommer la ligne) fonctionne à merveille pour tout le verbiage (y compris tous les prédicats attachés à la table). Inversement, le nom idiot "table représente le prédicat" ne peut pas. Ce qui est bien pour les "théoriciens", qui comprennent très peu les Prédicats, mais retardés autrement.

• Les prédicats qui sont pertinents pour le modèle de données, sont exprimés dans le modèle, ils sont de deux ordres.

  1. Prédicat unaire
     Le premier ensemble est schématique et non textuel: la notation elle-même . Ceux-ci incluent divers existentiels; Axé sur les contraintes; et Descripteur (attributs) Prédicats.

     • Bien sûr, cela signifie que seuls ceux qui peuvent «lire» un modèle de données standard peuvent lire ces prédicats. C'est pourquoi les «théoriciens», qui sont gravement paralysés par leur état d'esprit de texte uniquement, ne peuvent pas lire les modèles de données, pourquoi ils s'en tiennent à leur état d'esprit d'avant 1984 uniquement de texte.

  2. Prédicat binaire
     Le deuxième ensemble est celui qui forme des relations entre les faits. C'est la ligne de relation. La phrase verbale (détaillée ci-dessus) identifie le prédicat, la proposition , qui a été implémentée (qui peut être testée via une requête). On ne peut pas être plus explicite que cela.

     • Par conséquent, pour celui qui maîtrise parfaitement les modèles de données standard, tous les prédicats pertinents sont documentés dans le modèle. Ils n'ont pas besoin d'une liste séparée de prédicats (mais les utilisateurs, qui ne peuvent pas tout «lire» à partir du modèle de données, le font!).

• Voici un modèle de données , où j'ai répertorié les prédicats. J'ai choisi cet exemple car il montre les prédicats existentiels, etc., ainsi que ceux des relations, les seuls prédicats non répertoriés sont les descripteurs. Ici, en raison du niveau d'apprentissage du chercheur, je le traite comme un utilisateur.

Par conséquent, l'événement de plus d'une table enfant entre deux tables parentes n'est pas un problème, nommez-les simplement comme le fait existentiel relatif à leur contenu et normalisez les noms.

Les règles que j'ai données pour les phrases verbales pour les noms de relations pour les tables associatives entrent en jeu ici. Voici une discussion Prédicat vs Table , couvrant tous les points mentionnés, en résumé.

Pour une bonne brève description de l'utilisation correcte des prédicats et de la manière de les utiliser (ce qui est un contexte assez différent de celui de la réponse aux commentaires ici), visitez cette réponse et faites défiler jusqu'à la section Prédicat .

Charles Burns:
Par séquence, j'entendais l'objet de style Oracle purement utilisé pour stocker un numéro et son suivant selon une règle (par exemple "ajouter 1"). Étant donné qu'Oracle ne dispose pas de tables d'identification automatique, mon utilisation typique est de générer des ID uniques pour les PK de table. INSERT INTO foo (id, somedata) VALUES (foo_s.nextval, "data" ...)

Ok, c'est ce que nous appelons une table Key ou NextKey. Nommez-le comme tel. Si vous avez SubjectAreas, utilisez COM_NextKey pour indiquer qu'il est commun dans la base de données.

Btw, c'est une très mauvaise méthode de génération de clés. Pas du tout évolutif, mais avec les performances d'Oracle, c'est probablement "très bien". De plus, cela indique que votre base de données est pleine de substituts, et non relationnels dans ces domaines. Ce qui signifie des performances extrêmement médiocres et un manque d'intégrité.

Singulier vs pluriel: choisissez-en un et respectez-le.

Les colonnes ne doivent pas être préfixées / suffixées / infixées ou en tout cas fixées avec des références au fait qu'il s'agit d'une colonne. Il en va de même pour les tables. Ne nommez pas les tables EMPLOYEE_T ou TBL_EMPLOYEES car à la seconde où elles sont remplacées par une vue, les choses deviennent vraiment déroutantes.

N'intégrez pas les informations de type dans les noms, tels que "vc_firstname" pour varchar ou "flavour_enum". N'intégrez pas non plus de contraintes dans les noms de colonnes, telles que "department_fk" ou "employee_pk".

En fait, la seule bonne chose au sujet des corrections * Je peux penser, 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 nommez pas toutes les clés «ID». Les clés faisant référence à la même chose doivent avoir le même nom dans toutes les tables. La colonne ID utilisateur peut être appelée USER_ID dans la table utilisateur et toutes les tables référençant l'utilisateur. Le seul moment où il est renommé est lorsque différents utilisateurs jouent différents rôles, tels que Message (sender_user_id, receiver_user_id). Cela aide vraiment lors du traitement de requêtes plus volumineuses.

Concernant CaSe:

thisiswhatithinkofalllowercapscolumnnames.

ALLUPPERCAPSISNOTBETTERBECAUSEITFEELSLIKESOMEONEISSCREAMINGATME.

CamelCaseIsMarginallyBetterButItStillTakesTimeToParse.    

i_recommend_sticking_with_lower_case_and_underscore

En général, il est préférable de nommer les «tables de mappage» pour qu'elles correspondent à la relation qu'elles décrivent plutôt qu'aux noms des tables référencées. Un utilisateur peut avoir un certain nombre de relations aux produits: user_likes_product, user_bought_product, user_wants_to_buy_product.

Il n'y a pas de «correct» entre le singulier et le pluriel - c'est surtout une question de goût.

Cela dépend en partie de votre concentration. Si vous considérez le tableau comme une unité, il contient des «pluriels» (car il contient de nombreuses lignes - un nom au pluriel est donc approprié). Si vous pensez que le nom de la table identifie une ligne dans une table, vous préférerez «singulier». Cela signifie que votre SQL sera considéré comme travaillant sur une ligne de la table. Ce n'est pas grave, bien qu'il s'agisse généralement d'une simplification excessive; SQL fonctionne sur des ensembles (plus ou moins). Cependant, nous pouvons aller au singulier pour les réponses à cette question.

1. Puisque vous aurez probablement besoin d'une table «utilisateur», d'un autre «produit» et de la troisième pour connecter les utilisateurs aux produits, alors vous avez besoin d'une table «user_product».

2. Puisque la description s'applique à un produit, vous utiliseriez «product_description». À moins que chaque utilisateur ne nomme chaque produit pour lui-même ...

3. La table 'user_product' est (ou pourrait être) un exemple de table avec un ID produit et un ID utilisateur et pas grand-chose d'autre. Vous nommez les tables à deux attributs de la même manière générale: "user_stuff". Les préfixes décoratifs comme «rel_» n'aident pas vraiment. Vous verrez certaines personnes utiliser «t_» devant chaque nom de table, par exemple. Ce n’est pas beaucoup d’aide.

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

Je me dispenserais de souligner à moins que vous ne vouliez décrire une relation plusieurs-à-plusieurs; et utiliser un capital initial car il permet de distinguer les choses dans les ORM.

Mais il existe de nombreuses conventions de dénomination, donc si vous souhaitez utiliser des traits de soulignement, ce n'est pas grave tant que cela est fait de manière cohérente.

Alors:

User

UserProduct (it is a users products after all)

Si un seul utilisateur peut avoir un produit, alors

UserProductDescription

Mais si le produit est partagé par les utilisateurs:

ProductDescription

Si vous enregistrez vos traits de soulignement pour les relations plusieurs-à-plusieurs, vous pouvez faire quelque chose comme:

UserProduct_Stuff

pour former un M-à-M entre UserProduct et Stuff - pas sûr de la question de la nature exacte du plusieurs-à-plusieurs requis.

Il n'y a pas plus correct d'utiliser le singulier que le pluriel, où avez-vous entendu cela? Je dirais plutôt que la forme plurielle est plus courante pour nommer les tables de base de données ... et à mon avis aussi plus logique. Le tableau contient le plus souvent plus d'une ligne;) Dans un modèle conceptuel bien que les noms des entités soient souvent au singulier.

À propos de votre question, si «Produit» et «Description du produit» sont des concepts avec une identité (c'est-à-dire des entités) dans votre modèle, j'appellerais simplement les tableaux «Produits» et «Description des produits». Pour les tables utilisées afin d'implémenter une relation plusieurs-à-plusieurs, j'utilise le plus souvent la convention de dénomination "SideA2SideB", par exemple "Student2Course".