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 Customer
table 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 IDs
lesquels 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 KEY
dans 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::product
est 1 :: n. Ce qui compte, c'est de savoir s'il product
s'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 product
n'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_description
xor product_description
sera 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"?
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
).
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
Si vous vous retrouvez avec deux user_product
tables, 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.
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).
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.
Soyez très prévenant et nommez les tables et les colonnes avec beaucoup de précision . Ne pas utiliser UpdatedDate
s'il s'agit d'un DATETIME
type de données, utilisez UpdatedDtm
. Ne pas utiliser _description
s'il contient une dose.
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 / ItemNo
ou ItemNum
à un autre endroit pour indiquer le nombre d'articles. À utiliser NumSomething
pour les nombres 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 la table comme qualificatif:
table_name.column_name -- notice the dot
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_id
est la colonne qui identifie un utilisateur, pas le id
de la user
table.
- (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_product
table aura un user_id
comme composant de son PK (user_id, product_no)
.
- la pertinence de cela deviendra claire lorsque vous commencerez à coder. Premièrement, avec
id
de 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. AssemblyCode
et ComponentCode
pour deux PartCodes
. Et dans ce cas, n'utilisez pas l'indifférencié PartCode
pour l'un d'entre eux. Être précis.
Diagram_E
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).
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:
_V
Afficher (avec le principal TableName
devant, bien sûr)
_fk
Clé étrangère (le nom de la contrainte, pas le nom de la colonne) Transaction de segment de
_cac
cache (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
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_fk
séquence, ce n'est pas Child_Parent_fk
parce 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
.
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:
U
Unique, ou _
pour non-unique en
C
cluster, ou _
pour
_
séparateur non en cluster
Pour le reste:
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_CustomerId
ou Product.U__AK
apparaî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.
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:
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.
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 Product
c'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.
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.
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é.
primarily opinion-based
est manifestement faux.