Convenzione di denominazione chiave primaria / chiave esterna

Nel nostro gruppo di sviluppo abbiamo un acceso dibattito riguardo la convenzione di denominazione per le chiavi primarie e quelle 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 raccomandate in altre lingue, in cui non si utilizza il nome dell’object nei suoi nomi di proprietà. Penso che nominare la chiave esterna EmployeeID (o Employee_ID potrebbe essere migliore) dice al lettore che è la colonna ID della tabella dei Employee .

    Alcuni altri preferiscono l’opzione 2 dove si nomina la chiave primaria preceduta dal nome della tabella in modo che il nome della colonna sia lo stesso in tutto il database. Vedo quel punto, ma ora non è ansible 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 che la tabella sia un’ quadro e una colonna come una proprietà o un attributo di quell’entity framework, la pensi come l’attributo ID del Employee , non l’attributo EmployeeID di un dipendente. Non vado a chiedere al mio collega qual è il suo PersonAge o PersonGender . Gli chiedo qual è la sua età.

    Quindi, come ho detto, è un dibattito acceso e andiamo avanti all’infinito. Sono interessato ad avere alcune nuove prospettive.

    Non importa. Non ho mai incontrato un sistema in cui c’è una vera differenza tra la scelta 1 e la scelta 2.

    Jeff Atwood ha avuto un grande articolo un po ‘indietro su questo argomento. Fondamentalmente le persone discutono e discutono con la massima rabbia su quegli argomenti sui quali non possono essere smentiti. O da un punto di vista diverso, quegli argomenti che possono essere vinti solo attraverso argomenti di resistenza in stile filibuster basati sull’ultimo uomo.

    Scegline uno e digli di concentrarti sui problemi che hanno un impatto sul tuo codice.

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

    Se le due colonne hanno lo stesso nome in entrambe le tabelle (convenzione # 2), è ansible utilizzare la syntax USING in SQL per salvare un po ‘di digitazione e qualche rumore di boilerplate:

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

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

    Il significato di ciascuna colonna viene in parte comunicato etichettandolo con il nome del dominio corrispondente.

    Penso che dipenda dal modo in cui l’applicazione viene messa insieme. Se usi ORM o progetti le tabelle per rappresentare oggetti, l’opzione 1 potrebbe essere per te.

    Mi piace codificare il database come proprio livello. Controllo tutto e l’app chiama solo stored procedure. È bello avere set di risultati con nomi di colonne completi, specialmente quando ci sono molte tabelle unite e molte colonne restituite. Con questo stipo di applicazione, mi piace l’opzione 2. Mi piace molto vedere i nomi delle colonne corrispondenti ai join. Ho lavorato su vecchi sistemi in cui non corrispondevano ed era un incubo,

    Né la convenzione funziona in tutti i casi, quindi perché averne uno? Usa il senso comune…

    ad esempio, per la tabella autoreferenziale, quando ci sono più di una colonna FK che si auto-fa riferimento al PK della stessa tabella, DEVI violare entrambi gli “standard”, poiché le due colonne FK non possono essere denominate uguali … ad es. , EmployeeTable con EmployeeId PK, SupervisorId FK, MentorId Fk, PartnerId FK, …

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

    Se le persone iniziano a “fare le loro cose”, dovrebbero essere appiccicate dai loro nervi. A PARER MIO 🙂

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

    1. Le definizioni delle tabelle di solito si mappano direttamente su una class che descrive un object, quindi dovrebbero essere singolari. Per descrivere una collezione di un object, di solito aggiungo “Array” o “List” o “Collection” al nome singolare, in quanto è più chiaro che l’uso di plurali indica non solo che si tratta di una raccolta, ma che tipo di raccolta è. In quella vista, vedo un nome di tabella come non il nome della collezione, ma il nome del tipo di object di cui è una raccolta. Un DBA che non scrive il codice dell’applicazione potrebbe perdere questo punto.

    2. I dati che trattano spesso usano “ID” per scopi di identificazione non chiave. Per eliminare la confusione tra gli “ID” chiave e gli “ID” non chiave, per il nome della chiave primaria, usiamo “Chiave” (che è quello che è, non è vero?) Preceduta dal nome della tabella o da un’abbreviazione di il nome del tavolo. Questo prefisso (e lo riservo solo per la chiave primaria) rende il nome della chiave univoco, che è particolarmente importante perché utilizziamo nomi di variabili uguali ai nomi delle colonne del database e la maggior parte delle classi ha un genitore, identificato dal nome di la chiave genitore. Questo è necessario anche per assicurarsi che non sia una parola chiave riservata, che è solo la “Chiave”. Per facilitare la 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 più di una volta incontrato programmi che funzionano molto meglio in questo modo usando i join naturali. Su quest’ultimo punto, ammetto un problema con le tabelle autoreferenziali, che ho usato. In questo caso, farei un’eccezione alla regola di denominazione della chiave esterna. Ad esempio, utilizzare ManagerKey come chiave esterna nella tabella Employee per puntare a un altro record in quella tabella.

    Mi piace la convention # 2 – nella ricerca di questo argomento, e trovando 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 unendole a una seconda tabella che ha analogamente 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) al fine di rendere questi due valori univoci nel risultato, cioè:

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

    Anche se usare la convenzione # 2 significa che avrò ancora alcune colonne nel risultato con lo stesso nome, ora posso specificare quale ID ho bisogno (genitore o figlio) e, come suggerito da Steven Huwig, l’istruzione USING 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 usare userIdPK e userIdFK come nomi per identificarne uno dall’altro. Mi aiuterà a identificare rapidamente PK e FK quando guardo le tabelle e sembra che cancellerà il codice quando si utilizza PHP / SQL per accedere ai dati rendendone più facile la comprensione. Soprattutto quando qualcun altro guarda il mio codice.

    La convenzione che usiamo dove lavoro è molto vicina ad A, con l’eccezione che chiamiamo le tabelle in forma plurale (cioè “dipendenti”) e usiamo caratteri di sottolineatura tra la tabella e il nome della colonna. Il vantaggio è che fare riferimento a una colonna, è “employee _ id” o “employees.id”, a seconda di come si desidera accedervi. Se è necessario specificare da quale tabella proviene la colonna, “employees.employees _ id” è decisamente ridondante.

    Io uso la convenzione n. 2. Sto lavorando con un modello di dati legacy ora in cui non so cosa rappresenta una determinata tabella. Dov’è il danno nell’essere prolissi?

    Che ne dici di nominare la chiave esterna

    ROLE_ID

    dove il ruolo è il ruolo che l’ quadro di riferimento ha relativ alla tabella in questione. 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 tue proposte.

    In ogni caso havin lunghe discussioni è una ctriggers idea

    Hai preso in considerazione quanto segue?

     Primary Table (Employee) Primary Key is PK_Employee Foreign table (Event) Foreign key is called FK_Employee 

    “Where in” impiegato INNER JOIN ordine ON order.employee_id = employee.id “è necessaria una qualifica aggiuntiva?”.

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

    “il motivo per cui un utente aziendale fa riferimento a ID ordine o ID dipendente è fornire un contesto, ma a livello di base si dispone già di un contesto perché si sta arbitrando sulla tabella”.

    Per favore, dimmi, se la colonna è denominata ‘ID’, allora come è fatto esattamente il “refereing [sic] al tavolo”, a meno che qualificando questo riferimento alla colonna ID esattamente nel modo in cui ho parlato?