Convenzione di denominazione chiave primaria / chiave esterna [chiusa]

Nel nostro gruppo di sviluppo abbiamo un acceso dibattito sulla convenzione di denominazione per le chiavi primarie e straniere. Ci sono fondamentalmente due scuole di pensiero nel nostro gruppo:

1:

Primary Table (Employee)   
Primary Key is called ID

Foreign table (Event)  
Foreign key is called EmployeeID

o

2:

Primary Table (Employee)  
Primary Key is called EmployeeID

Foreign table (Event)  
Foreign key is called EmployeeID

Preferisco non duplicare il nome della tabella in nessuna delle colonne (quindi preferisco l'opzione 1 sopra). Concettualmente, è coerente con molte delle pratiche consigliate in altre lingue, in cui non si utilizza il nome dell'oggetto nei nomi delle proprietà. Penso che nominare la chiave esterna EmployeeID(o Employee_IDpotrebbe essere migliore) dica al lettore che è la IDcolonna della Employeetabella.

Alcuni altri preferiscono l'opzione 2 in cui si nomina la chiave primaria con il prefisso del nome della tabella in modo che il nome della colonna sia lo stesso in tutto il database. Capisco quel punto, ma ora non puoi distinguere visivamente una chiave primaria da una chiave esterna.

Inoltre, penso che sia ridondante avere il nome della tabella nel nome della colonna, perché se pensi alla tabella come un'entità e una colonna come una proprietà o un attributo di quell'entità, la pensi come l'attributo ID del Employee, non l' EmployeeIDattributo di un dipendente. Non vado a chiedere al mio collega che cosa sia PersonAgeo che PersonGendersia. Gli chiedo qual è la sua età.

Quindi, come ho detto, è un dibattito furioso e continuiamo all'infinito. Mi interessa avere nuove prospettive.

Non importa davvero. Non mi sono mai imbattuto in un sistema in cui c'è una reale differenza tra la scelta 1 e la scelta 2.

Jeff Atwood ha pubblicato un ottimo articolo su questo argomento qualche tempo fa. Fondamentalmente le persone discutono e discutono più furiosamente quegli argomenti su cui non possono essere smentite. O da una prospettiva diversa, quegli argomenti che possono essere vinti solo attraverso argomenti ostili basati sulla resistenza.

Scegline uno e dì loro di concentrarsi sui problemi che hanno effettivamente un impatto sul tuo codice.

EDIT: Se vuoi divertirti, chiedi loro di specificare a lungo perché il loro metodo è superiore per i riferimenti di tabella ricorsivi.

Se le due colonne hanno lo stesso nome in entrambe le tabelle (convenzione n. 2), puoi utilizzare la sintassi USING in SQL per risparmiare un po 'di digitazione e un po' di rumore boilerplate:

SELECT name, address, amount
  FROM employees JOIN payroll USING (employee_id)

Un altro argomento a favore della convenzione n. 2 è che è il modo in cui è stato progettato il modello relazionale .

Il significato di ogni colonna è parzialmente trasmesso etichettandolo con il nome del dominio corrispondente.

Penso che dipenda da come la tua applicazione è stata composta. Se utilizzi ORM o progetti le tue tabelle per rappresentare oggetti, l'opzione 1 potrebbe fare al caso tuo.

Mi piace codificare il database come un proprio livello. Controllo tutto e l'app chiama solo stored procedure. È bello avere set di risultati con nomi di colonna completi, specialmente quando ci sono molte tabelle unite e molte colonne restituite. Con questo tipo di applicazione, mi piace l'opzione 2. Mi piace molto vedere la corrispondenza dei nomi delle colonne sui join. Ho lavorato su vecchi sistemi in cui non corrispondevano ed è stato un incubo,

Nessuna delle due convenzioni funziona in tutti i casi, quindi perché averne una? Usa il senso comune...

ad esempio, per la tabella autoreferenziale, quando ci sono più di una colonna FK che auto-referenzia il PK della stessa tabella, DEVI violare entrambi gli "standard", poiché le due colonne FK non possono avere lo stesso nome ... es. , EmployeeTable con EmployeeId PK, SupervisorId FK, MentorId Fk, PartnerId FK, ...

Sono d'accordo che c'è poco da scegliere tra di loro. Per me una cosa molto più significativa di entrambi gli standard è la parte "standard".

Se le persone iniziano a "fare le proprie cose", dovrebbero essere impiccate. A PARER MIO :)

Hai considerato quanto segue?

Primary Table (Employee)   
Primary Key is PK_Employee

Foreign table (Event)  
Foreign key is called FK_Employee

La convenzione che usiamo dove lavoro è molto simile alla A, con l'eccezione che nominiamo le tabelle nella forma plurale (cioè "impiegati") e usiamo trattini bassi tra il nome della tabella e quello della colonna. Il vantaggio è che per fare riferimento a una colonna, è "dipendenti _ id" o "dipendenti.id", a seconda di come si desidera accedervi. Se è necessario specificare da quale tabella proviene la colonna, "dipendenti.employees _ id" è decisamente ridondante.

Se stai guardando il codice dell'applicazione, non solo le query del database, alcune cose mi sembrano chiare:

1. Le definizioni di tabella di solito si associano direttamente a una classe che descrive un oggetto, quindi dovrebbero essere singolari. Per descrivere una raccolta di un oggetto, di solito aggiungo "Array" o "List" o "Collection" al nome singolare, poiché più chiaramente dell'uso dei plurali indica non solo che si tratta di una raccolta, ma che tipo di raccolta è. In quella vista, vedo il nome di una tabella non come il nome della raccolta, ma il nome del tipo di oggetto di cui è una raccolta. Un DBA che non scrive il codice dell'applicazione potrebbe perdere questo punto.

2. I dati che trattano spesso utilizzano "ID" per scopi di identificazione non chiave. Per eliminare la confusione tra "ID" chiave e "ID" non chiave, per il nome della chiave primaria, utilizziamo "Chiave" (è quello che è, non è vero?) Preceduto dal nome della tabella o da un'abbreviazione di il nome della tabella. Questo prefisso (e lo riservo solo per la chiave primaria) rende il nome della chiave univoco, il che è particolarmente importante perché usiamo nomi di variabili che sono gli stessi dei nomi delle colonne del database e la maggior parte delle classi ha un genitore, identificato dal nome di la chiave genitore. Anche questo è necessario per assicurarsi che non sia una parola chiave riservata, come la sola "Chiave". Per facilitare il mantenimento della coerenza dei nomi delle variabili chiave e per fornire programmi che eseguono join naturali, le chiavi esterne hanno lo stesso nome utilizzato nella tabella in cui sono la chiave primaria. Ho incontrato più di una volta programmi che funzionano molto meglio in questo modo utilizzando i join naturali. Su quest'ultimo punto ammetto un problema con le tabelle autoreferenziali, che ho utilizzato. In questo caso, farei un'eccezione alla regola di denominazione delle chiavi esterne. Ad esempio, utilizzerei ManagerKey come chiave esterna nella tabella Employee per puntare a un altro record in quella tabella.

Mi piace la convenzione n. 2: nella ricerca di questo argomento e nel trovare questa domanda prima di pubblicare la mia, mi sono imbattuto nel problema in cui:

Sto selezionando * da una tabella con un numero elevato di colonne e unendola a una seconda tabella che allo stesso modo ha un numero elevato di colonne. Entrambe le tabelle hanno una colonna "id" come chiave primaria, e ciò significa che devo selezionare specificamente ogni colonna (per quanto ne so) per rendere questi due valori univoci nel risultato, ovvero:

SELECT table1.id AS parent_id, table2.id AS child_id

Sebbene l'uso della convenzione n. 2 significhi che avrò ancora alcune colonne nel risultato con lo stesso nome, ora posso specificare di quale ID ho bisogno (genitore o figlio) e, come suggerito da Steven Huwig, l' USINGistruzione semplifica ulteriormente le cose.

Ho sempre usato userId come PK su una tabella e userId su un'altra tabella come FK. Sto seriamente pensando di utilizzare userIdPK e userIdFK come nomi per identificare l'uno dall'altro. Mi aiuterà a identificare PK e FK rapidamente quando guardo le tabelle e sembra che chiarirà il codice quando si utilizza PHP / SQL per accedere ai dati rendendolo più facile da capire. Soprattutto quando qualcun altro guarda il mio codice.

Uso la convenzione n. 2. Ora sto lavorando con un modello di dati legacy in cui non so cosa significhi in una determinata tabella. Dov'è il male nell'essere verboso?

Che ne dici di nominare la chiave esterna

role_id

dove ruolo è il ruolo che l'entità di riferimento ha rispetto al tavolo a portata di mano. Questo risolve il problema del riferimento ricorsivo e di più fks sulla stessa tabella.

In molti casi sarà identico al nome della tabella di riferimento. In questo caso diventa identico a una delle vostre proposte.

In ogni caso avere lunghe discussioni è una cattiva idea

"Where in" Employee INNER JOIN order ON order.employee_id = Employee.id "è necessaria una qualifica aggiuntiva?".

Non c'è bisogno di qualifiche aggiuntive perché la qualifica di cui ho parlato è già lì.

"il motivo per cui un utente aziendale fa riferimento all'ID ordine o all'ID dipendente è per fornire il contesto, ma a livello di base hai già il contesto perché ti riferisci alla tabella".

Per favore, dimmi, se la colonna si chiama "ID", allora come viene eseguita esattamente quella "referenza [sic] al tavolo", a meno che non qualifichi questo riferimento alla colonna ID esattamente nel modo in cui ho parlato?