Comment nommer une table qui mappe deux tables ensemble? [fermé]

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 mappe la couleur à la forme?

Table: ???
Columns: ColorId, ShapeId

Il n'y a que deux choses difficiles en informatique: l'invalidation du cache et la dénomination des choses
- Phil Karlton

Trouver un bon nom pour une table qui représente une many-to-manyrelation rend la relation plus facile à lire et à comprendre. Parfois, trouver un bon nom n'est pas anodin, mais cela vaut généralement la peine de réfléchir.

Un exemple: Readeret Newspaper.

A Newspapera beaucoup Readerset a Readera beaucoupNewspapers

Vous pouvez appeler la relation, NewspaperReadermais un nom comme celui-ci Subscriptionpourrait mieux expliquer ce qu'est la table.

Le nom Subscriptionest également plus idiomatique au cas où vous voudriez mapper la table à des objets plus tard.

La convention de dénomination des many-to-manytables est une concaténation des noms des deux tables impliquées dans la relation. ColourShapeserait un défaut raisonnable dans votre cas. Cela dit, je pense que Nick D a fait deux excellentes suggestions: Styleet Texture.

Que diriez-vous de ColorShapeMap ou Style ou Texture .

Intéressant, environ la moitié des réponses donnent un terme général pour tout tableau qui implémente une relation plusieurs-à-plusieurs, et l'autre moitié des réponses suggèrent un nom pour ce tableau 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 dans la relation plusieurs-à-plusieurs. Donc, dans ce cas, " ColorShape" ou " ShapeColor." Mais je trouve que cela semble artificiel et gênant.

Joe Celko recommande dans son livre "SQL Programming Style" de nommer ces tables d'une manière en langage naturel. 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 Colorqu'avec une convention de dénomination plurielle. Trop déroutant.

Probablement le plus clair d'utiliser la ColoredByconvention de dénomination. Il est intéressant de noter que l'utilisation de la voix passive rend la convention de dénomination plus claire.

Nommez le tableau comme vous le souhaitez, à condition qu'il soit informatif:

COLOR_SHAPE_XREF

Du point de vue du modèle, la table est appelée table de jointure / corrollaire / référence croisée. J'ai gardé l'habitude d'utiliser _XREFà la fin pour rendre la relation évidente.

Il s'agit d'une entité associative et est assez souvent significative en soi.

Par exemple, une relation plusieurs à plusieurs entre les TRAINS et les TEMPS donne lieu à un HORAIRE.

S'il n'y a pas de nouvelle entité évidente (telle que calendrier), alors la convention est d'exécuter les deux mots ensemble, en donnant COLOUR_SHAPE ou similaire.

Une table de mappage est ce que l'on appelle généralement.

ColorToShape
ColorToShapeMap

J'ai travaillé avec des DBA qui l'appellent une table de jointure .

Colour_Shape est assez typique - à moins que la relation n'ait un nom spécifique au domaine explicite.

J'entends généralement cela appelé une table de jonction. Je nomme la table en fonction de ce qu'elle rejoint, donc dans votre cas, soit ColorShape, soit ShapeColor. Je pense qu'il est plus logique pour une forme d'avoir une couleur que pour une couleur d'avoir une forme, alors j'irais avec ShapeColor.

Junction table

OU Bridge Table

OU Join Table

OU Map Table

OU Link Table

OU Cross-Reference Table

Ceci est utilisé lorsque nous optons pour des relations plusieurs-à-plusieurs où les clés des deux tables forment la clé primaire composite de la table de jonction.

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 = Couleurs Formes

Table intermédiaire ou table de jointure

Je l'appellerais "ColorShapes" ou "ColorShape", selon vos préférences

J'ai également entendu le terme table associative utilisé.

un nom pour votre tableau peut ColorShapeAssociationssignifier que chaque ligne représente une association entre cette couleur et cette forme. L'existence d'une ligne implique que la couleur se présente sous cette forme et que la forme se présente dans cette couleur. Toutes les lignes avec une couleur spécifique seraient l'ensemble de toutes les formes auxquelles la couleur est associée, et les lignes pour une forme spécifique seraient l'ensemble de toutes les couleurs dans lesquelles la forme est entrée ...

En général, la plupart des bases de données ont une sorte de convention de dénomination pour les index, la clé primaire, etc. Dans PostgreSQL, la dénomination suivante a été suggérée:

• clé primaire: nom_table_nom_colonne_ nom_table_nom_colonne_pkey
• contrainte unique: nom_table_nom_colonne_ clé
• contrainte exclusive: nom_table_nom_colonne_ excl
• index à d'autres fins: nom_table_nom_colonne_idx
• clé étrangère: nom_table_nom_colonne_fkey
• séquence: nom_table_nom_colonne_ seq
• déclencheurs: nom_table_actionnom_after | avant_ trig

Votre table est une table liée pour moi. Pour rester en ligne avec la dénomination ci-dessus, je choisirais ce qui suit:

• table liée: nomtable1_nomtable2_ lnk

Dans une liste d'objets de table, la table liée sera après nomtable1. Cela pourrait être visuellement plus attrayant. Mais vous pouvez également choisir un nom qui décrit le but du lien comme d'autres l'ont suggéré. Cela peut aider à garder le nom de la colonne id court (si votre lien doit avoir son propre id nommé et est référencé dans d'autres tables).

• ou table aimée: purposename_ lnk

J'ai toujours été partial pour le terme "Hamburger Table". Je ne sais pas pourquoi - ça sonne bien.

Oh, et j'appellerais la table ShapeColor ou ColorShape en fonction de la table la plus couramment utilisée.

Table "plusieurs-plusieurs". Je l'appellerais "ColourShape" ou vice versa.

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 après quelque chose dans le domaine réel au lieu d'une description générique des relations sous-jacentes.

Très souvent, ce type de table évoluera vers quelque chose de plus riche pour le modèle de domaine et prendra des attributs supplémentaires au-dessus et au-delà des clés étrangères liées.

Par exemple, que se passe-t-il si vous devez stocker une texture en plus de la couleur? Il peut sembler un peu génial d'étendre la table SHAPE_COLOR pour conserver sa texture.

D'un autre côté, il y a aussi quelque chose à dire pour prendre une décision éclairée en fonction des exigences que vous avez aujourd'hui et être prêt à refactoriser lorsque des exigences supplémentaires seront introduites plus tard.

Cela dit, je l'appellerais SURFACE si j'avais une idée qu'il y aurait des propriétés de surface supplémentaires 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.

Peut-être juste ColoredShape?

Je ne suis pas sûr d'avoir compris la question. S'agit-il de ce cas spécifique ou recherchez-vous des directives générales?

Je le nommerais avec les noms exacts des tables jointes = ColorShape.

En adiction à ce que Developer Art a lié,

ColorShape

serait une convention de dénomination habituelle. Dans le diagramme ER, ce serait une relation.

Appelez cela une table de références croisées.

XREF_COLOR_SHAPE
(
     XCS_ID INTEGER
     C_ID   INTEGER
     S_ID   INTEGER
)

J'utiliserais r_shape_colorsou r_shape_colorselon sa signification.
r_serait un remplacement pour xref_dans ce cas.

Mon vote est pour un nom qui décrit le mieux le tableau. Dans ce cas, c'est peut-être le cas, ShapeColormais dans de nombreux cas, un nom différent d'une concaténation est préférable. J'aime la lisibilité et pour moi , cela signifie pas de suffixes, pas de traits de soulignement et pas de préfixes.

Personnellement, je choisirais Colour_Shape, avec le trait de soulignement: juste parce que j'ai vu cette convention apparaître un peu. [mais d'accord avec les autres messages ici qu'il y a probablement des façons plus «poétiques» de faire cela].

Gardez à l'esprit que les clés étrangères doivent également être construites sur cette table de jointure qui ferait référence à la fois aux tables Couleur et Forme, ce qui aiderait également à identifier la relation.

Une convention que je vois beaucoup pour joindre des tables que j'aime personnellement est «Colour_v_Shape», que j'ai entendu des gens appeler familièrement «versus tables».

Cela montre très clairement en un coup d'œil que le tableau représente une relation plusieurs-à-plusieurs, et permet d'éviter cette situation déroutante (bien que rare) lorsque vous essayez de concaténer deux mots qui pourraient autrement former un mot composé, par exemple `` beurre '' et «Milk» peut devenir «ButterMilk», mais que faire si vous deviez également représenter une entité appelée «Buttermilk»?

En procédant de cette façon, vous auriez 'Butter_v_Milk' et 'Buttermilk' - pas de confusion.

De plus, j'aime penser qu'il y a une référence à Foo Fighters dans la question originale.