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

137

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

— devuxer
source

Alias ColorShape et ShapeColor pour la symétrie.

— LukLed

2

Je viens de tomber sur une question similaire que je n'avais pas vue auparavant: stackoverflow.com/questions/1764483/… . D'autres idées de ce fil: Shape2Color, ShapeXColor, ShapeColorLink.

— devuxer

S'il y avait une norme de dénomination des tables de jonction - alors ce ne serait pas basé sur les opnions. Alors ça aurait été la réponse à la question. En fermant la question, vous empêchez quelqu'un comme moi de savoir s'il existe des moyens standard de nommer vos tables de jonction ou non. Veuillez reconsidérer - ceux qui l'ont fermé ...

— Lealo

187

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.

— tosh
source

10

+1: bien dit - un nom soigneusement choisi maintenant rendra la maintenabilité beaucoup plus facile à l'avenir.

— Preet Sangha

115

"Il n'y a que deux choses difficiles en informatique: l'invalidation du cache, la dénomination des choses et les erreurs ponctuelles"

— Neil McGuigan

1

disons, s'il existe une catégorie pour les produits et une autre catégorie pour la recette. pour les deux tables, nous aurons recette_categories et product_categories, et comme nous ne pouvons pas simplement "categories" nom de table pour les deux tables, afin d'éviter le conflit, les tables de jonction pour le produit et la recette seront "recette_recipe_categories" et "product_product_categories"

— c9s

3

Les informations de connexion strictement logiques ne signifient pas l'ajout de nouvelles informations. Je pense que c'est ce qui se passe lorsque vous essayez de trouver un mot approprié pour les tables de jonction. Les gens qui lisent les journaux ne font pas d'eux des abonnés et il n'y a pas de formes sans couleur. Utiliser des «abonnés» ajoute de nouvelles informations (sens) lors de la connexion des lecteurs aux journaux. Et il n'y a pas de mots pour décrire le lien entre la forme et la couleur - il n'y a jamais eu quelque chose du contraire, donc pas de nom pour cela. N'oubliez pas qu'il n'y a pas de nouveaux attributs donnés dans une table de jonction.

— Lealo

35

Que diriez-vous de ColorShapeMap ou Style ou Texture .

— Nick Dandoulakis
source

5

+1 pour proposer quelque chose de plus élégant que de simplement joindre les noms des tables

— tosh

22

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.

— Bill Karwin
source

Bill, merci. Réponse très intéressante.

— devuxer

@Bill: Tout sur les synonymes et la préférence des synonymes a un impact sur la convention de dénomination.

— OMG Ponies

2

Je suppose que cela HasColorpourrait être un autre nom possible pour la table d'intersection qui utilise le langage naturel.

— Bill Karwin

1

@Bill: Le problème que j'ai avec cette convention de dénomination est hasColour/ ColouredBypour quoi? Cela va à l'encontre du but de nommer à utiliser DESCRIBEpour découvrir les relations.

— OMG Ponies

5

Semblable au commentaire d'OMG Ponies, que se passe-t-il si d'autres choses peuvent avoir une couleur? Si j'ai une autre table qui mappe le texte à la couleur, j'aurais besoin d'un nom unique. Peut ShapeHasColor- être et TextHasColor?

— devuxer

20

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.

— Poneys OMG
source

1

J'utilise aussi _XREF ... ça a toujours du sens pour moi.

— James Cronen

Je creuse l'idée, mais en tant qu'utilisateur d'AutoCAD, je dois trouver un suffixe différent de _XREF ...

— Mike

7

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.

— Ed Guiness
source

6

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

ColorToShape
ColorToShapeMap

En fait, le terme Mapping est généralement utilisé lorsque la relation est unidirectionnelle (un à un ou plusieurs). Est-ce le caswe? Si tel est le cas, vous n'avez généralement pas besoin d'une autre table. Si la couleur détermine toujours la forme, ajoutez une colonne de forme à la table des couleurs, ou vice versa. Une table supplémentaire n'est généralement nécessaire que lorsque la relation est plusieurs à plusieurs. Et dans ce cas, le terme mapping n'est pas approprié.

— Charles Bretana

Dans ce cas, n'importe quelle forme peut être assortie à n'importe quelle couleur, donc c'est plusieurs-à-plusieurs.

— devuxer

2

BTW, que ce soit une table de mappage ou non, j'aime un peu l'idée d'utiliser Todans le nom. Que faire si vous avez Shape avec HighlightColor. Si vous l'appelez ShapeHighlightColor, il est un peu ambigu qu'il s'agisse d'un ShapeHighlight mappé à une couleur ou d'une Shape mappé à une couleur de surbrillance. Donc, ShapeToHighlightColorpeut-être plus clair.

— devuxer

FYI: Oracle (9i / 10g de toute façon) a une limite de 32 caractères pour les noms de table, vous ne pouvez donc pas être trop verbeux.

— OMG Ponies

J'ai utilisé la réponse ci-dessus mais d'une manière un peu différente. c'est-à-dire Color_Shape_Map. Convention: Table1_Table2_Map

— Goldfish

6

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.

— Dafydd Rees
source

1

Je n'aime pas les traits de soulignement car ils sont en conflit avec les conventions de dénomination des clés étrangères, de sorte que vous vous retrouvez avec des noms méchants comme Colour_Shape_Colouret Colour_Shape_Shape.

— Dan Bechard

4

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.

— Bill le lézard
source

4

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.

— priyanka.sarkar
source

4

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

— Palindromère
source

Si vous utilisez la route des "noms de tables", c'est mieux car la version singulière serait "généralement" une table à espaces de noms.

— Andrew Haust

3

Table intermédiaire ou table de jointure

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

— Neil N
source

3

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 ...

— Charles Bretana
source

Mais comment nommeriez-vous la table réelle?

— devuxer

Cela dépend de ce que le tableau décrit. Si cela dit «tout ce qui est orange doit être un losange», «tout ce qui est violet doit être un cercle», etc., alors vous pouvez l'appeler une chose (Colour_of_Shape, peut-être). S'il s'agit d'une définition plus lâche - des couleurs connues pour les formes, permettant à une seule forme d'apparaître plusieurs fois - alors peut-être «Shape_Colour_Map».

— Jonathan Leffler

2

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

— Frankenstein
source

1

Bonne vieille notation hongroise, nous nous revoyons.

— Dan Bechard

1

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.

— rêne
source

1

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

— gbn
source

1

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.

— Joe Holloway
source

1

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?

— mafu
source

0

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

— DOK
source

0

En adiction à ce que Developer Art a lié,

ColorShape

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

— Jaestevan
source

0

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

XREF_COLOR_SHAPE
(
     XCS_ID INTEGER
     C_ID   INTEGER
     S_ID   INTEGER
)

— EvilTeach
source

0

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

— Marius Burz
source

0

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.

— magnus
source

0

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.

— monojohnny
source

0

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.

— Breeno
source