Come dovrei nominare una tabella che associa due tabelle insieme? [chiuso]

Diciamo che ho due tabelle:

Table: Color
Columns: Id, ColorName, ColorCode

Table: Shape
Columns: Id, ShapeName, VertexList

Come dovrei chiamare la tabella che associa il colore alla forma?

Table: ???
Columns: ColorId, ShapeId

In Informatica ci sono solo due cose difficili: invalidare la cache e nominare cose
: Phil Karlton

Trovare un buon nome per una tabella che rappresenta una many-to-manyrelazione rende la relazione più facile da leggere e comprendere. A volte trovare un grande nome non è banale ma di solito vale la pena dedicare un po 'di tempo a pensarci.

Un esempio: Readere Newspaper.

A Newspaperha molti Readerse a Readerha moltiNewspapers

Potresti chiamare la relazione, NewspaperReaderma un nome simile Subscriptionpotrebbe trasmettere meglio di cosa tratta la tabella.

Il nome Subscriptionè anche più idiomatico nel caso in cui si desideri mappare la tabella su oggetti in un secondo momento.

La convenzione per la denominazione delle many-to-manytabelle è una concatenazione dei nomi di entrambe le tabelle coinvolte nella relazione. ColourShapesarebbe un default ragionevole nel tuo caso. Detto questo, credo che Nick D si avvicinò con due ottimi consigli: Stylee Texture.

Che ne dici di ColorShapeMap o Style o Texture .

Interessante circa la metà delle risposte dà un termine generale per qualsiasi tabella che implementa una relazione molti-a-molti, e l'altra metà delle risposte suggerisce un nome per questa tabella specifica.

Ho chiamato queste tabelle tabelle di intersezioni in generale.

In termini di convenzioni di denominazione, molte persone danno un nome che è un amalgama delle due tabelle nella relazione molti-a-molti. Quindi, in questo caso, " ColorShape" o " ShapeColor." Ma trovo che questo appaia artificiale e imbarazzante.

Joe Celko raccomanda nel suo libro "SQL Programming Style" di nominare queste tabelle in modo naturale. Ad esempio, se una forma è colorata da un colore, allora dai un nome alla tabella ColoredBy. Quindi potresti avere un diagramma che più o meno legge naturalmente in questo modo:

Shape <-- ColoredBy --> Color

Al contrario, potresti dire che un colore colora una forma:

Color <-- Colors --> Shape

Ma sembra che il tavolo di mezzo sia lo stesso Colordi una convenzione di denominazione plurale. Troppo confuso.

Probabilmente è più chiaro usare la ColoredByconvenzione di denominazione. È interessante notare che l'uso della voce passiva rende più chiara la convenzione di denominazione.

Dai un nome alla tabella come preferisci, purché sia ​​informativo:

COLOR_SHAPE_XREF

Dal punto di vista del modello, la tabella è denominata tabella join / corrollary / riferimento incrociato. Ho mantenuto l'abitudine di utilizzare _XREFalla fine per rendere evidente la relazione.

Questa è un'entità associativa ed è abbastanza spesso significativa a sé stante.

Ad esempio, una relazione da molte a molte tra TRENI e ORARI dà origine a un ORARIO.

Se non ci sono nuove entità ovvie (come gli orari), allora la convenzione è di eseguire le due parole insieme, dando COLOUR_SHAPE o simili.

Una tabella di mapping è ciò che viene generalmente chiamato.

ColorToShape
ColorToShapeMap

Ho lavorato con DBA che lo definiscono una tabella di join .

Colour_Shape è abbastanza tipico, a meno che la relazione non abbia un nome specifico di dominio esplicito.

Di solito sento quello chiamato un tavolo di giunzione. Prendo il nome della tabella da ciò che unisce, quindi nel tuo caso ColorShape o ShapeColor. Penso che abbia più senso che una forma abbia un colore piuttosto che una forma abbia un colore, quindi vorrei andare avanti ShapeColor.

Junction table

O Bridge Table

O Join Table

O Map Table

O Link Table

O Cross-Reference Table

Ciò viene utilizzato quando si utilizzano relazioni molti-a-molti in cui le chiavi di entrambe le tabelle formano la chiave primaria composita della tabella di giunzione.

Consiglio di usare una combinazione dei nomi delle entità e metterle al plurale. Pertanto, il nome della tabella esprimerà la connessione "molti-a-molti".

Nel tuo caso:

Color + Shape = ColorsShapes

Tabella intermedia o tabella di join

Lo chiamerei "ColorShapes" o "ColorShape", a seconda delle tue preferenze

Ho anche sentito il termine tabella associativa usata.

potrebbe essere un nome per il tuo tavolo ColorShapeAssociations significare che ogni riga rappresenta un'associazione tra quel colore e quella forma. L'esistenza di una riga implica che il colore abbia quella forma e che la forma abbia quel colore. Tutte le righe con un colore specifico sarebbero l'insieme di tutte le forme a cui è associato il colore e le righe per una forma specifica sarebbero l'insieme di tutti i colori in cui la forma è venuta ...

In generale, la maggior parte dei database ha una sorta di convenzione di denominazione per indici, chiave primaria e così via. In PostgreSQL è stata suggerita la seguente denominazione:

• chiave primaria: tablename_columnname_ pkey
• vincolo univoco: tablename_columnname_ key
• vincolo esclusivo: tablename_columnname_ escl
• indice per altri scopi: tablename_columnname_ idx
• chiave esterna: tablename_columnname_ fkey
• sequenza: tablename_columnname_ seq
• trigger: tablename_actionname_after | before_ trig

La tua tabella è una tabella collegata per me. Per rimanere in linea con la denominazione sopra, sceglierei quanto segue:

• tabella collegata: tablename1_tablename2_ lnk

In un elenco di oggetti tabella la tabella collegata sarà dopo tablename1. Questo potrebbe essere visivamente più attraente. Ma potresti anche scegliere un nome che descriva lo scopo del link come altri hanno suggerito. Ciò potrebbe aiutare a mantenere breve il nome della colonna id (se il collegamento deve avere il proprio id denominato ed è referenziato in altre tabelle).

• o tabella piaciuta: purposename_ lnk

Sono sempre stato parziale al termine "Hamburger Table". Non so perché - suona bene.

Oh, e chiamerei la tabella ShapeColor o ColorShape a seconda di quale sia la tabella più comunemente usata.

Tabella "Many-Many". Lo chiamerei "ColourShape" o viceversa.

È difficile rispondere a qualcosa di arbitrario come questo, ma tendo a preferire l'idea di tosh di nominarlo come qualcosa nel dominio effettivo piuttosto che una descrizione generica delle relazioni sottostanti.

Molto spesso questo tipo di tabella si evolverà in qualcosa di più ricco per il modello di dominio e assumerà ulteriori attributi sopra e oltre le chiavi esterne collegate.

Ad esempio, cosa succede se è necessario memorizzare una trama oltre al colore? Potrebbe sembrare un po 'strano espandere la tabella SHAPE_COLOR per mantenerne la trama.

D'altra parte, c'è anche qualcosa da dire per prendere una decisione ben informata sulla base di quali requisiti hai oggi e per essere pronto a rifattorizzare quando ulteriori requisiti verranno introdotti in seguito.

Detto questo, lo chiamerei SUPERFICIE se avessi la visione che sarebbero state introdotte ulteriori proprietà simili alla superficie. In caso contrario, non avrei problemi a chiamarlo SHAPE_COLOR o qualcosa del genere e passare a problemi di progettazione più urgenti.

Forse solo ColoredShape?

Non sono sicuro di avere la domanda. Riguarda questo caso specifico o stai cercando linee guida generali?

Lo nominerei con i nomi esatti delle tabelle che vengono unite = ColorShape.

In aggiunta a ciò che la Developer Art ha messo in relazione,

ColorShape

sarebbe una solita convenzione di denominazione. Nel diagramma ER, sarebbe una relazione.

Chiamalo una tabella di riferimenti incrociati.

XREF_COLOR_SHAPE
(
     XCS_ID INTEGER
     C_ID   INTEGER
     S_ID   INTEGER
)

Userei r_shape_colorso a r_shape_colorseconda del suo significato.
r_sarebbe una sostituzione xref_in questo caso.

Il mio voto è per un nome che descriva al meglio la tabella. In questo caso potrebbe essere, ShapeColorma in molti casi è meglio un nome diverso da una concatenazione. Mi piace la leggibilità e per me ciò significa nessun suffisso, nessun trattino basso e nessun prefisso.

Personalmente sceglierei Colour_Shape, con il trattino basso: solo perché ho visto alzare un po 'questa convenzione. [ma concordi con gli altri post qui che probabilmente ci sono modi più "poetici" per farlo].

Tenere presente che anche le chiavi esterne devono essere costruite su questa tabella di join che farebbe riferimento sia alle tabelle Color & Shape che aiuterebbero anche a identificare la relazione.

Una convenzione che vedo molto per unirmi ai tavoli che mi piace personalmente è "Colour_v_Shape", che ho sentito che le persone chiamano colloquialmente "contro i tavoli".

A prima vista chiarisce che la tabella rappresenta una relazione molti-a-molti e aiuta a evitare quella (sebbene rara) situazione confusa quando si tenta di concatenare due parole che potrebbero altrimenti formare una parola composta, ad esempio "Burro" e "Milk" può diventare "ButterMilk", ma se fosse necessario rappresentare anche un'entità chiamata "Buttermilk"?

In questo modo, avresti "Butter_v_Milk" e "Buttermilk" - nessuna confusione.

Inoltre, mi piace pensare che ci sia un riferimento a Foo Fighters nella domanda originale.