Convention de nommage des tables relationnelles

Question

Je commence un nouveau projet et j'aimerais que mes noms de tables et de colonnes soient corrects 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" puis des produits que seul l'utilisateur aura, la table devrait-elle s'appeler "produit_utilisateur" ou simplement "produit"? C'est une relation un à plusieurs.

Et plus loin, si j'avais (pour une raison quelconque) plusieurs descriptions de produit pour chaque produit, s'agirait-il de "description_produit_utilisateur" ou de "description_produit" ou simplement de "description"? Bien sûr, avec le jeu de clés étrangères correct .. Nommer uniquement la description serait problématique car je pourrais aussi avoir une description de l'utilisateur ou une description du 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 "user_product"?

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

Merci

PerformanceDBA · Accepted Answer

Table • Nom

le singulier récemment appris est correct

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

Voici quelques-uns des avantages des normes:

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 la table standard fait référence à chaque row de la table, qui est utilisé dans tout le verbiage, pas dans son contenu total (nous savons que le Customer table contient tous les clients).

Relation, Phrase verbale

Dans de véritables bases de données relationnelles modélisées (par opposition aux systèmes de classement des enregistrements d’avant 1970) [caractérisés par Record IDs qui 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 elles sont noms, encore une fois, singulier
les relations entre les tables sont les Actions qui ont lieu entre les noms, donc ils sont verbes (c'est-à-dire qu'ils ne sont pas numérotés ou nommés de manière arbitraire)
que est le Predicate
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 haut dans une hiérarchie) est qu'il est indépendant)
ainsi Phrase verbale est choisi avec soin, pour que ce soit le sens le plus significatif, 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 à la résolution du modèle, c'est-à-dire. clarifier les relations, identifier les erreurs et corriger les noms des tables.

Diagram_A

Bien entendu, la relation est implémentée dans SQL en tant que CONSTRAINT FOREIGN KEY dans la table enfant (plus, plus tard). Voici le Phrase verbale (dans le modèle), le Predicate qu'il représente (à lire dans le modèle) et le FK Nom de contrainte :

 Initiates Each Customer Initiates 0-to-n SalesOrders Customer_Initiates_SalesOrder_fk

Table • Langage

Cependant, en décrivant le tableau, en particulier dans un langage technique tel que les prédicats, ou dans d’autres documents, utilise le singulier et les pluriels tels qu’ils se trouvent naturellement en anglais. Gardez à l'esprit que la table est nommée pour la ligne unique (relation) et que le langage fait référence à 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 que je reçois des produits que seul l'utilisateur aura, la table devrait-elle s'appeler "utilisateur-produit" ou simplement "produit"? C'est une relation un à plusieurs.

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

Et si product n'existe que dans le contexte d'un user, c'est-à-dire. c'est un Table dépendante , donc user_product.

Diagram_B

Et plus tard, si j'avais (pour une raison quelconque) plusieurs descriptions de produits pour chaque produit, s'agirait-il de "description de produit par l'utilisateur" ou de "description de produit" ou simplement de "description"? Bien sûr, avec les bonnes clés étrangères définies. Nommer uniquement cette description serait problématique, car je pourrais aussi avoir une description de l’utilisateur ou une description du compte ou autre.

C'est vrai. Non plus user_product_description xor product_description sera correct, sur la base de ce qui précède. Ce n'est pas pour le différencier des autres xxxx_descriptions, mais c’est pour donner au nom une idée de son origine, le préfixe étant la table parente.

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

Espérons que toutes les tables de la base de données relationnelle sont de simples tables relationnelles normalisées. Il n'est pas nécessaire d'identifier cela dans le nom (sinon, toutes les tables seront rel_something).
S'il contient seulement les PK des deux parents (ce qui résout la relation logique n :: n qui n'existe pas en tant qu'entité au niveau de la niveau logique, dans une table physique), c’est-à-dire un 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 en parent, en ignorant la table enfant, car son seul but dans la vie est de mettre en relation les deux parents.
  
  Diagram_C
- Si c’est pas une table associative (c’est-à-dire qu’en plus des deux PC, elle contient des données), nommez-la de manière appropriée et les phrases verbales s’appliquent à elle, pas le parent à la fin. de la relation.
  
  Diagram_D
Si vous vous retrouvez avec deux user_product tables, c’est un signal très fort indiquant que vous n’avez pas normalisé les données. Alors, revenez en arrière et faites-le, et nommez les tables avec précision et cohérence. Les noms vont alors se résoudre.

Convention de nommage

Toute aide est très appréciée et s’il existe une sorte de convention de désignation 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’obtenir le plus de compréhension possible dès le début. La pertinence de la plupart de ceci ne sera pas claire, jusqu'à ce que vous commenciez à coder en SQL.

Case est le premier élément à adresser. Toutes les majuscules sont inacceptables. Les cas mixtes sont normaux, surtout si les tables sont directement accessibles par les utilisateurs. Reportez-vous mes modèles de données. Notez que lorsque le chercheur utilise une version non-SQL démente, elle n’a que des lettres minuscules, je donne cela, auquel cas j’inclus des traits de soulignement (selon vos exemples).
Conservez un data focus , pas une application ou un focus d'utilisation. Après 2011, nous avions Open Architecture depuis 1984, et les bases de données sont censées être indépendantes des applications qui les utilisent.

Ainsi, à mesure qu'ils grandissent et que plus d'une application les utilise, la dénomination restera significative et ne nécessitera aucune correction. (Les bases de données complètement intégrées à une seule application ne sont pas des bases de données.) Nommez les éléments de données en tant que données uniquement.
Soyez très prévenant, et nommez les tables et les colonnes très avec précision . N'utilisez pas UpdatedDate s'il s'agit d'un type de données DATETIME, utilisez UpdatedDtm. Ne pas utiliser_description s'il contient un dosage.
Il est important d’être cohérent dans la base de données. N'utilisez pas NumProduct à un endroit pour indiquer le nombre de produits et ItemNo ou ItemNum à un autre endroit pour indiquer le nombre d'éléments. Utilisez NumSomething pour les numéros de, et SomethingNo ou SomethingId pour les identificateurs, de manière cohérente.
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 table comme qualificatif:
```
 table_name.column_name -- notice the dot 
```
Exceptions:
- La première exception concerne les PC, elles nécessitent un traitement spécial car vous les codez dans les jointures à tout moment et vous souhaitez que les clés se distinguent des colonnes de données. Toujours utiliser user_id, jamais id.
  - Notez que ceci est pas un nom de table utilisé comme préfixe, mais un nom descriptif correct pour le composant de la clé: user_id est la colonne qui identifie un utilisateur, pas le id de la table user.
    - (Sauf bien sûr dans les systèmes de classement d'archives, où les fichiers sont accédés par des mères porteuses et où il n'y a pas de clés relationnelles, il s'agit d'une seule et même chose).
  - Utilisez toujours le même nom exact pour la colonne de clé partout où la PK est transportée (migrée) en tant que FK.
  - Par conséquent, la user_product table aura un user_id en tant que composant de sa PC (user_id, product_no).
  - la pertinence de ceci deviendra claire lorsque vous commencerez à coder. Premièrement, avec un id sur plusieurs tables, il est facile d’être mélangé dans le codage SQL. Deuxièmement, quiconque autre que le codeur initial n'a aucune idée de ce qu'il essayait de faire. Ces deux problèmes sont faciles à éviter si les colonnes de clé sont traitées comme ci-dessus.
- La deuxième exception concerne les cas où plusieurs FK référençant la même table de table parent, sont transportés dans l'enfant. Selon le Modèle relationnel, utilisez Role Names == pour différencier le sens ou l'usage, par exemple. AssemblyCode et ComponentCode pour deux PartCodes. Et dans ce cas, utilisez not == utilisez le PartCode non différencié pour l’un d’eux. Être précis.
  
  Diagram_E
Préfixe
Si vous avez plus que 100 tables, préfixez les noms de table avec un domaine:

REF_ pour les tables de référence
OE_ pour le groupe de saisie des commandes, etc.

Seulement au niveau physique, pas logique (cela encombre le modèle).
Suffixe
N'utilisez jamais de suffixe 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’existe aucun trait de soulignement; mais du point de vue administratif, les traits de soulignement sont utilisés comme séparateurs:

_V View (avec le TableName principal devant, bien sûr)
_fk Clé étrangère (le nom de la contrainte, pas le nom de la colonne)
_cac Cache
_seg Segment
_tr Transaction (proc ou fonction stockée)
_fn Fonction (non transactionnelle), etc.

Le format est le nom de la table ou du 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 envoie 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
clés étrangères (la contrainte, pas la colonne). La meilleure dénomination pour un FK consiste à utiliser la phrase verbale (moins le "each" et la cardinalité).

Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk

Utilisez le Parent_Child_fk séquence, pas Child_Parent_fk est parce que (a) il apparaît dans le bon ordre de tri lorsque vous les recherchez et (b) nous savons toujours que l’enfant est impliqué, ce que nous devinons, c’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, où les expressions verbales ont été identifiées. Pour le reste, les systèmes de classement des enregistrements, etc., utilisent Parent_Child_fk.
Les indices sont spéciaux, ils ont donc leur propre convention de nommage, composée de dans l’ordre, chaque position de caractère de 1 à 3:

U Unique ou _ pour non unique
C Clustered, ou _ pour non-cluster
_ séparateur

Pour le reste:
- Si la clé est une colonne ou très peu de colonnes:
  ____ ColumnNames
- Si la clé est plus que quelques colonnes:
  ____ PK Clé primaire (selon le modèle)
  ____AK[*n*] Clé secondaire (terme IDEF1X)
Notez que le nom de la table est pas requis dans le nom de l'index, car il apparaît toujours sous la forme table_name.index_name.

Donc quand Customer.UC_CustomerId ou Product.U__AK apparaît dans un message d'erreur, il vous dit quelque chose de significatif. Lorsque vous regardez les indices sur une table, vous pouvez les différencier facilement.
Trouvez une personne qualifiée et professionnelle et suivez-la. Examinez leurs conceptions 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. Réciproquement, courez comme un diable de quiconque fait peu de cas des conventions ou des normes de nommage. En voici quelques-uns 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 sûr, les modèles implémentent plusieurs autres Normes, au-delà des conventions de dénomination; vous pouvez soit les ignorer pour le moment, soit vous pouvez poser des questions spécifiques nouvelles questions .
- Il y a plusieurs pages chacune, la prise en charge des images en ligne dans Stack Overflow est destinée aux oiseaux, et elles ne se chargent pas de manière uniforme sur différents navigateurs; vous devrez donc cliquer sur les liens.
- Notez que PDF ont une navigation complète. Cliquez donc sur les boutons en verre bleu ou sur les objets pour lesquels une expansion est identifiée:
- Les lecteurs qui ne sont pas familiers avec le standard de modélisation relationnelle trouveront peut-être le IDEF1X Notation ) utile.

Entrée de commande et inventaire avec des adresses conformes à la norme

Simple inter-bureau Bulletin système pour PHP/MyNonSQL

Surveillance du capteur == avec capacité temporelle totale

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 montre ...
Si un client a des produits de zéro à plusieurs et qu'un produit a des composants de un à plusieurs et qu'un composant a des fournisseurs de un à plusieurs et qu'un fournisseur vend des composants de zéro à plusieurs et qu'un représentant des ventes en possède un -to-Plusieurs clients 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:

Vous déclarez que votre exemple est "le plus trivial", cependant, c'est tout sauf cela. Avec ce genre de contradiction, je ne sais pas si vous êtes sérieux, si vous êtes techniquement capable.
Cette spéculation "triviale" comporte plusieurs erreurs grossières de normalisation (conception de base de données).
- Tant que vous ne corrigez pas ces erreurs, elles sont anormales et non naturelles et elles n’ont aucun sens. Vous pourriez 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 achetant des produits sans aucun instrument commercial (tels que Facture ou SalesOrder) comme base d'achat (ou les clients "possèdent-ils" des produits?); relations non résolues plusieurs à plusieurs; 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 demande. Ce qui signifie que je devrai ajouter un sens à cela, ne sachant pas ce que vous vouliez dire, alors s'il vous plaît, supportez-moi. Les erreurs grossières sont trop nombreuses pour être énumérées, et compte tenu de la spécification de réserve, je ne suis pas sûr de les avoir toutes corrigées.

Je suppose que si le produit est composé de composants, il est un assemblage et les composants sont utilisés dans plusieurs assemblages.
En outre, puisque "le fournisseur vend des composants de zéro à plusieurs", c'est-à-dire qu'il vend pas, il ne vend que des composants.

Spéculation vs modèle normalisé

Au cas où vous ne le sauriez pas, la différence entre les coins carrés (indépendants) et arrondis (dépendants) est importante, veuillez vous reporter au lien IDEF1X Notation. De même, les lignes continues (identification) et les lignes pointillées (non-identification).

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

Client
Produit
Composant (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. Peut-être pouvez-vous poser une question spécifique .

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

En supposant qu’il n’y ait pas d’erreur de normalisation, User likes Product est un prédicat, pas une table. Ne les confondez pas. Reportez-vous à ma réponse, où elle se rapporte aux sujets, aux verbes et aux prédicats, et à ma réponse à Larry immédiatement ci-dessus.

Chaque table contient un set de faits (chaque ligne est un fait). Les prédicats (ou propositions) ne sont pas des faits, ils peuvent être vrais ou non vrais.
- Le modèle relationnel est basé sur le calcul du prédicat du premier ordre (plus communément appelé logique du premier ordre). Un prédicat est une phrase à une clause rédigée dans un anglais simple et précis, évaluée comme étant vraie ou fausse.
- De plus, chaque table représente, ou est l’implémentation de, many Prédicats, pas un.
Une requête est un test d'un prédicat (ou d'un nombre de prédicats, chaînés) aboutissant à true (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 nommage), pour la ligne, le fait et les prédicats doivent être documentés (par tous les moyens, cela fait partie de la documentation de la base de données), mais en tant que 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 ne l’écrirai pas ici.
Vite alors. Puisque le modèle relationnel est fondé sur FOPC, on peut dire que la base de données entière est 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 prédicat (c’est l’implémentation physique de many , et de types de prédicats).
Par conséquent, nommer la table pour "le" prédicat qu'il "représente" est un concept absurde.
Les "théoriciens" ne connaissent que quelques prédicats, ils ne comprennent pas que, puisque [~ ~ ~] rm [~ # ~] a été fondée sur la FOL, la base de données entière est un ensemble de prédicats, et de différents types.
- Et bien sûr, ils choisissent des absurdes parmi ceux 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 "tableau idiot du prédicat" ne peut pas le nom. Ce qui est bien pour les "théoriciens", qui comprennent très peu les prédicats, mais qui sont retardés autrement.
Les prédicats pertinents pour le modèle de données sont exprimés dans le modèle, ils sont de deux ordres.
1. Unary Predicate
  Le premier ensemble est diagrammatic, pas le texte: la notation elle-même . Ceux-ci incluent divers existentiels; Orienté vers la contrainte; et descripteur (attributs) prédicats.
  - Bien entendu, 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", gravement handicapés par leur mentalité de texte seulement, ne peuvent pas lire les modèles de données, ils restent donc fidèles à leur mentalité d’avant-1984.
2. Binary Predicate
  Le deuxième ensemble est celui qui forme relations entre faits. C'est la ligne de relation. La phrase verbale (détaillée ci-dessus) identifie le prédicat, proposition, qui a été implémenté (et qui peut être testé via une requête). On ne peut pas être plus explicite que cela.
  - Par conséquent, pour celui qui maîtrise couramment les modèles de données standard, tous les prédicats qui sont 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 du modèle de données, le font!).
Voici un Data Model , ==, où j'ai répertorié les prédicats. J'ai choisi cet exemple car il montre les prédicats existentiel, etc., ainsi que les prédicats relationnels, les seuls prédicats non répertoriés étant les descripteurs. Ici, en raison du niveau d'apprentissage du chercheur, je le traite en tant qu'utilisateur.

Par conséquent, l’événement de plus d’une table enfant entre deux tables parent n’est pas un problème, il suffit de les nommer en tant que faits existentiels concernant leur contenu et de normaliser les noms.

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

Pour une brève description de l'utilisation correcte des prédicats et de leur utilisation (contexte différent de celui de la réponse aux commentaires ici), visitez le site == ( this answer , et faites défiler jusqu'à la section Predicate .

Charles Burns:
Par séquence, je voulais dire l’objet de style Oracle purement utilisé pour stocker un nombre et le suivant conformément à une règle (par exemple, "ajouter 1"). Comme Oracle n’a pas de table d’identification automatique, mon utilisation habituelle est de générer des ID uniques pour les PK de table. INSERT INTO foo (id, somedata) VALEURS (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 à la base de données.

Btw, c'est une très mauvaise méthode de génération de clés. Pas évolutif du tout, 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 relationnelle dans ces domaines. Ce qui signifie des performances extrêmement médiocres et un manque d'intégrité.

Jonathan Leffler · Answer

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

Cela dépend en partie de votre concentration. Si vous considérez la table comme une unité, elle contient des "pluriels" (car elle contient plusieurs 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 le terme "singulier". Cela signifie que votre code SQL sera considéré comme fonctionnant sur une ligne de la table. Ce n'est pas grave, bien que ce soit généralement une simplification excessive. SQL fonctionne sur des ensembles (plus ou moins). Cependant, nous pouvons aller au singulier pour les réponses à cette question.

Étant donné que vous aurez probablement besoin d'une table 'utilisateur', d'un autre 'produit' et du troisième pour connecter les utilisateurs aux produits, vous avez besoin d'une table 'produit_utilisateur'.
Puisque la description s'applique à un produit, vous utiliseriez 'description_produit'. À moins que chaque utilisateur nomme chaque produit pour lui-même ...
La table 'user_product' est (ou pourrait être) un exemple de table avec un ID de produit et un ID d'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 tels que 'rel_' ne m'aident pas vraiment. Vous verrez certaines personnes utiliser "t_" devant chaque nom de table, par exemple. Ce n'est pas beaucoup d'aide.

Ronnis · Answer

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

Les colonnes ne doivent pas être préfixées/suffixées/infixées ni en aucun cas fixées avec des références au fait qu'il s'agit d'une colonne. La même chose vaut 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 d'informations de type dans les noms, tels que "vc_firstname" pour varchar ou "flavour_enum". Aussi, n'incorporez pas de contraintes dans les noms de colonnes, tels que "department_fk" ou "employee_pk".

En fait, la seule bonne chose à propos des * corrections auxquelles je puisse penser, est que vous pouvez utiliser des mots réservés tels que where_t, tbl_order, user_vw. Bien sûr, dans ces exemples, utiliser le 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 user et toutes les tables référençant l'utilisateur. Il est renommé uniquement lorsque différents utilisateurs jouent différents rôles, tels que Message (sender_user_id, receiver_user_id). Cela aide vraiment lorsqu'il s'agit de requêtes plus volumineuses.

En ce qui concerne CaSe:

thisiswhatithinkofalllowercapscolumnnames. ALLUPPERCAPSISNOTBETTERBECAUSEITFEELSLIKESOMEONEISSCREAMINGATME. CamelCaseIsMarginallyBetterButItStillTakesTimeToParse. i_recommend_sticking_with_lower_case_and_underscore

En général, il est préférable de nommer "tables de mappage" pour correspondre à la relation décrite, plutôt qu'aux noms des tables référencées. Un utilisateur peut avoir un nombre quelconque de relations avec des produits: user_likes_product, user_bought_product, user_wants_to_buy_product.

amelvin · Answer

Les pluriels ne sont pas mauvais tant qu'ils sont utilisés régulièrement - mais ma préférence va au singulier.

Je me passerais des traits de soulignement à moins que vous ne vouliez décrire une relation plusieurs à plusieurs; et utilisez un capital initial car il aide à distinguer les choses dans les ORM.

Mais il existe de nombreuses conventions de dénomination, donc si vous voulez utiliser des traits de soulignement, c'est bien tant que c'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 des relations multiples, vous pouvez effectuer les opérations suivantes:

UserProduct_Stuff

former un M-to-M entre UserProduct et Stuff - je ne suis pas sûr de la question de la nature exacte de la multiplicité requise.

Ozzy · Answer

Il n’est 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 commune 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, les noms des entités sont souvent au singulier.

Concernant votre question, si "Produit" et "ProductDescription" sont des concepts ayant une identité (c'est-à-dire des entités) dans votre modèle, j'appellerais simplement les tableaux "Produits" et "ProductDescriptions". 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".