Comment dois-je nommer une table qui associe deux tables?
Disons que j'ai deux tables:
Table: Color
Columns: Id, ColorName, ColorCode
Table: Shape
Columns: Id, ShapeName, VertexList
Comment dois-je appeler le tableau qui associe la couleur à la forme?
Table: ???
Columns: ColorId, ShapeId
Il n’ya que deux choses difficiles en informatique: l’invalidation du cache et le nommage
- Phil Karlton
Venir avec un bon nom pour une table qui représente un many-to-many relation rend la relation plus facile à lire et à comprendre. Parfois, trouver un bon nom n’est pas anodin, mais il vaut généralement la peine de réfléchir.
Un exemple: Reader et Newspaper.
Un Newspaper a beaucoup de Readers et un Reader a beaucoup de Newspapers
Vous pouvez appeler la relation NewspaperReader mais un nom comme Subscription pourrait mieux expliquer le rôle de la table.
Le nom Subscription est également plus idiomatique si vous souhaitez mapper la table à des objets ultérieurement.
La convention pour nommer many-to-many tables est une concaténation des noms des deux tables impliquées dans la relation. ColourShape serait un défaut judicieux dans votre cas. Cela dit, je pense que Nick D est venu avec deux excellentes suggestions: Style et Texture.
Que diriez-vous de ColorShapeMap ou Style ou Texture.
Intéressant, environ la moitié des réponses donne un terme général pour toute table qui implémente une relation plusieurs à plusieurs, et l’autre moitié des réponses suggère un nom pour cette table spécifique.
J'ai appelé ces tables tables d'intersections en général.
En termes de conventions de dénomination, la plupart des gens donnent un nom qui est un amalgame des deux tables de la relation plusieurs à plusieurs. Donc, dans ce cas, "ColorShape" ou "ShapeColor." Mais je trouve que cela a l'air artificiel et maladroit.
Joe Celko recommande dans son livre "SQL Programming Style" de nommer ces tables de manière naturelle. Par exemple, si une forme est colorée par une couleur, nommez la table ColoredBy. Ensuite, vous pourriez avoir un diagramme qui se lit plus ou moins naturellement comme ceci:
Shape <-- ColoredBy --> Color
Inversement, vous pouvez dire qu'une couleur colore une forme:
Color <-- Colors --> Shape
Mais cela ressemble à la table du milieu est la même chose que Color avec une convention de nommage plurielle. Trop déroutant.
C'est probablement plus clair d'utiliser la convention de nommage ColoredBy. Il est intéressant de noter que l’utilisation de la voix passive rend la convention de nommage plus claire.
Nommez la table comme bon vous semble, à condition qu'elle soit informative:
COLOR_SHAPE_XREF
Du point de vue du modèle, la table s'appelle une table join/corrollaire/référence croisée. J'ai gardé l'habitude d'utiliser _XREF à la fin pour rendre la relation évidente.
Une table de correspondance est ce que cela s'appelle habituellement.
ColorToShape
ColorToShapeMap
Ceci est un Entité associative et est assez souvent significatif en soi.
Par exemple, une relation plusieurs à plusieurs entre TRAINS et TIMES donne lieu à un TIMETABLE.
S'il n'y a pas de nouvelle entité évidente (telle que le calendrier), la convention consiste à exécuter les deux mots ensemble, en donnant COLOUR_SHAPE ou similaire.
J'entends généralement cela appelé une table de jonction. Je nomme la table en fonction de ce à quoi elle se joint. Dans votre cas, ColorShape ou ShapeColor. Je pense qu'il est plus logique pour une forme d'avoir une couleur que pour une couleur, donc j'irais avec ShapeColor.
[~ # ~] ou [~ # ~] Bridge Table
[~ # ~] ou [~ # ~] Join Table
[~ # ~] ou [~ # ~] Map Table
[~ # ~] ou [~ # ~] Link Table
[~ # ~] ou [~ # ~] Cross-Reference Table
Cela entre en vigueur lorsque nous recherchons des relations plusieurs à plusieurs, dans lesquelles les clés des deux tables forment la clé primaire composite de la table de jonction.
J'ai travaillé avec des DBA qui l'appellent un table de jointure.
Colour_Shape est assez typique - à moins que la relation ait un nom explicite spécifique à un domaine.
Table intermédiaire ou a Table de jointure
Je l'appellerais "ColorShapes" ou "ColorShape", selon vos préférences
Je recommande d'utiliser une combinaison des noms d'entités et de les mettre au pluriel. Ainsi, le nom de la table exprimera la connexion "plusieurs-à-plusieurs".
Dans ton cas:
Couleur + Forme = CouleursFormes
En général, la plupart des bases de données ont une sorte de convention de nommage pour les index, les clés primaires, etc. Dans PostgreSQL, la dénomination suivante a été suggérée:
- clé primaire: nom_table_nom_colonne _pkey
- contrainte unique: nom_table_nom_table _clé
- contrainte exclusive: tablename_columnname _excl
- index à d'autres fins: tablename_columnname _idx
- clé étrangère: nom_table_nom_colonne _fkey
- séquence: nom_table_nom_colonne _seq
- triggers: tablename_actionname_after | before _trig
Votre table est une table liée à moi. Pour rester en ligne avec le nom ci-dessus, je choisirais ce qui suit:
- table liée: nom_table1 nom_table2 _lnk
Dans une liste d'objets de table, la table liée se trouvera après le nom_table1. Cela pourrait être plus attrayant visuellement. Mais vous pouvez également choisir un nom décrivant le but du lien, comme d'autres l'ont suggéré. Cela pourrait aider à garder le nom de la colonne id bref (si votre lien doit avoir son propre id nommé et est référencé dans d'autres tables).
- ou table préférée: nom_posposition _lnk
J'ai aussi entendu le terme associatif table utilisé.
le nom de votre table pourrait être ColorShapeAssociations, ce qui signifie que chaque ligne représente une association entre cette couleur et cette forme. L'existence d'une ligne implique que la couleur a cette forme et que la forme a cette couleur. Toutes les lignes avec une couleur spécifique seraient l'ensemble des formes auxquelles la couleur est associée, et les lignes d'une forme spécifique seraient l'ensemble de toutes les couleurs de la forme entrée ...
Il est difficile de répondre à quelque chose d'aussi arbitraire que cela, mais j'ai tendance à préférer l'idée de tosh de le nommer d'après quelque chose du domaine réel plutôt qu'une description générique des relations sous-jacentes.
Très souvent, ce type de table évoluera pour devenir quelque chose de plus riche pour le modèle de domaine et adoptera des attributs supplémentaires au-delà des clés étrangères liées.
Par exemple, si vous avez besoin de stocker une texture en plus de la couleur? Il peut sembler un peu génial d’étendre la table SHAPE_COLOR pour qu’elle conserve sa texture.
D'autre part, il y a aussi quelque chose à dire pour prendre une décision éclairée en fonction des exigences que vous avez aujourd'hui et pour être prêt à reformuler lorsque des exigences supplémentaires sont introduites ultérieurement.
Cela dit, je l'appellerais SURFACE si j'avais bien compris qu'il y aurait des propriétés supplémentaires de type surface introduites plus tard. Sinon, je n'aurais aucun problème à l'appeler SHAPE_COLOR ou quelque chose du genre et à passer à des problèmes de conception plus urgents.
"Plusieurs-Plusieurs" table. Je l'appellerais "ColorShape" ou vice versa.
J'ai toujours été partisan du terme "Table Hamburger". Je ne sais pas pourquoi - ça sonne bien.
Oh, et j'appellerais la table ShapeColor ou ColorShape selon la table la plus utilisée.
Peut-être que ColoredShape?
Je ne suis pas sûr d'avoir la question. S'agit-il de ce cas spécifique ou cherchez-vous des directives générales?
Personnellement, je choisirais Colour_Shape, avec le trait de soulignement: juste parce que j’ai vu cette convention se concrétiser assez souvent. [mais convenez avec les autres posts ici qu'il y a probablement plus de manières "poétiques" de le faire].
N'oubliez pas que les clés étrangères doivent également être construites sur cette table de jointure, qui référencerait les tables Color & Shape, ce qui faciliterait également l'identification de la relation.
Une convention que je vois souvent pour rejoindre les tables et que j'aime personnellement est "Colour_v_Shape", ce que j'ai entendu dire par beaucoup de gens qu'on appelle couramment "versus tables".
En un coup d'œil, il est très clair que le tableau représente une relation plusieurs à plusieurs et permet d'éviter cette situation déroutante (même si elle est rare) lorsque vous essayez de concaténer deux mots qui pourraient sinon former un mot composé, par exemple, "Butter". et 'Milk' peut devenir 'Buttermilk', mais si vous deviez également représenter une entité appelée 'Buttermilk'?
En procédant de cette manière, vous obtiendrez 'Butter_v_Milk' et 'Buttermilk' - pas de confusion.
J'aime aussi penser qu'il y a une référence à Foo Fighters dans la question initiale.
Je le nommerais avec les noms exacts des tables jointes = ColorShape.
En dépendance de ce que Developer Art a lié,
ColorShape
serait une convention de nommage habituelle. Dans le diagramme ER, ce serait une relation.
Mon vote est pour un nom qui décrit le mieux la table. Dans ce cas, il peut s'agir de ShapeColor, mais dans de nombreux cas, un nom différent de celui d'une concaténation est préférable. J'aime la lisibilité et pour moi, cela signifie qu'aucun suffixe, aucun trait de soulignement et aucun préfixe.
J'utiliserais r_shape_colors ou r_shape_color en fonction de sa signification.r_ serait un remplaçant pour xref_ dans ce cas.
Appelez cela une table de références croisées.
XREF_COLOR_SHAPE
(
XCS_ID INTEGER
C_ID INTEGER
S_ID INTEGER
)