Domanda

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
È stato utile?

Soluzione

  

Ci sono solo due cose difficili dentro   Informatica: invalidazione della cache   e denominazione delle cose
- Phil Karlton

Trovare un buon nome per una tabella che rappresenta una relazione molti-a-molti semplifica la lettura e la comprensione della relazione. A volte trovare un grande nome non è banale ma di solito vale la pena dedicare un po 'di tempo a pensare.

Un esempio: Reader e Newspaper .

Un giornale ha molti lettori e un Reader ha molti Newspapers

Potresti chiamare la relazione NewspaperReader ma un nome come Subscription potrebbe comunicare meglio di cosa tratta la tabella.

Il nome Sottoscrizione è anche più idiomatico nel caso in cui si desideri mappare la tabella sugli oggetti in seguito.

La convenzione per nominare le tabelle many-to-many è una concatenazione dei nomi di entrambe le tabelle coinvolte nella relazione. ColourShape sarebbe un valore predefinito ragionevole nel tuo caso. Detto questo, penso che Nick D è arrivato con due grandi suggerimenti: Style e Texture .

Altri suggerimenti

Che ne dici di ColorShapeMap o Stile 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 delle intersezioni in generale.

In termini di convenzioni di denominazione, la maggior parte delle persone dà un nome che è un amalgama delle due tabelle nella relazione molti-a-molti. Quindi, in questo caso, " ColorShape " o " ShapeColor . " Ma trovo questo aspetto artificiale e imbarazzante.

Joe Celko raccomanda nel suo libro "Stile di programmazione SQL" per dare un nome a 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 legge più o meno 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 di Color con una convenzione di denominazione plurale. Troppo confuso.

Probabilmente è più chiaro usare la convenzione di denominazione ColoredBy . È 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 preso l'abitudine di usare _XREF alla fine per rendere evidente la relazione.

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

ColorToShape
ColorToShapeMap

Questa è una entità associativa ed è spesso significativa di per sé.

Ad esempio, molte o molte relazioni tra TRENI e ORARI danno origine a un ORARIO.

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

Di solito sento che si chiama una tabella 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 di un colore, quindi vorrei andare con ShapeColor .

Ho lavorato con DBA che lo chiamano tabella di join .

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

Tabella di giunzione

OPPURE Bridge table

OPPURE Partecipa alla tabella

OPPURE Tabella mappe

OPPURE Tabella collegamenti

OPPURE Tabella di riferimenti incrociati

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.

Tabella intermedia o una Tabella di partecipazione

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

Raccomando 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

Ho anche sentito il termine tabella Associative usato.

un nome per la tua tabella potrebbe essere ColorShapeAssociations , il che significa 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_ chiave
  • 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. Questo potrebbe aiutare a mantenere breve il nome della colonna id (se il tuo link deve avere il proprio id denominato ed è referenziato in altre tabelle).

  • o tabella piaciuta: purposename_ lnk

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

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

" molti-molti " tavolo. 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 proprietà simili alla superficie aggiuntive in seguito. 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 da unire = ColorShape.

In aggiunta a ciò che l'arte dello sviluppatore ha messo in relazione,

ColorShape

sarebbe una normale 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_colors o r_shape_color a seconda del suo significato.
r_ sostituirà xref_ in questo caso.

Il mio voto è per un nome che descrive meglio la tabella. In questo caso potrebbe essere ShapeColor ma in molti casi è meglio un nome diverso da una concatenazione. Mi piace la leggibilità e per me , ciò significa nessun suffisso, nessun carattere di sottolineatura e nessun prefisso.

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

Ricorda che anche le chiavi esterne dovrebbero essere costruite su questa tabella di join che farebbe riferimento sia a Color & amp; Tabelle di forma che aiuterebbero anche a identificare la relazione.

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

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 "Butter" e "Milk" possono 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.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top