Perché specificare gli attributi della chiave primaria / esterna nei nomi delle colonne

Question

Un paio di domande recenti discutono le strategie per la denominazione delle colonne e sono stato piuttosto sorpreso di scoprire il concetto di incorporare la nozione di chiavi esterne e primarie nei nomi delle colonne. Questo è

select t1.col_a, t1.col_b, t2.col_z
from t1 inner join t2 on t1.id_foo_pk = t2.id_foo_fk

Devo confessare di non aver mai lavorato su alcun sistema di database che utilizza questo tipo di schema e mi chiedo quali siano i vantaggi. Per come la vedo io, dopo aver appreso le N tabelle principali di un sistema, scriverai diversi ordini di grandezza più richieste con quelle tabelle.

Per diventare produttivi nello sviluppo, devi imparare quali tabelle sono le tabelle importanti e quali sono semplici affluenti. Ti consigliamo di assegnare un buon numero di nomi di colonna alla memoria. E una delle attività di base è quella di unire due tavoli insieme. Per ridurre lo sforzo di apprendimento, la cosa più semplice da fare è assicurarsi che il nome della colonna sia lo stesso in entrambe le tabelle:

select t1.col_a, t1.col_b, t2.col_z
from t1 inner join t2 on t1.id_foo = t2.id_foo

Suppongo che, come sviluppatore, non sia necessario ricordare che molto di quali colonne sono le chiavi primarie, quali sono estranee e quali non sono nulla. È abbastanza facile guardare lo schema se sei curioso. Quando guardi un casuale

tx inner join ty on tx.id_bar = ty.id_bar

... è così importante sapere quale è la chiave esterna? Le chiavi esterne sono importanti solo per il motore di database stesso, per consentirgli di garantire l'integrità referenziale e fare la cosa giusta durante gli aggiornamenti e le eliminazioni.

Quale problema viene risolto qui? (So ??che questo è un invito a discutere e mi sento libero di farlo. Ma allo stesso tempo, sto cerco una risposta, in quanto potrei davvero mancare qualcosa).

Answer 1

Sono d'accordo con te sul fatto che la colonna chiave esterna in una tabella figlio dovrebbe avere lo stesso nome della colonna chiave primaria nella tabella padre. Si noti che ciò consente la sintassi come la seguente:

SELECT * FROM foo JOIN bar USING (foo_id);

La parola chiave USING presuppone che esista una colonna con lo stesso nome in entrambe le tabelle e che si desideri un equi-join. È bello avere questo disponibile come scorciatoia per i più dettagliati:

SELECT * FROM foo JOIN bar ON (foo.foo_id = bar.foo_id);

Nota, tuttavia, ci sono casi in cui non puoi nominare la chiave esterna allo stesso modo della chiave primaria a cui fa riferimento. Ad esempio, in una tabella che ha un riferimento personale:

CREATE TABLE Employees (
  emp_id INT PRIMARY KEY,
  manager_id INT REFERENCES Employees(emp_id)
);

Inoltre, una tabella può avere più chiavi esterne nella stessa tabella padre. È utile utilizzare il nome della colonna per descrivere la natura della relazione:

CREATE TABLE Bugs (
  ...
  reported_by INT REFERENCES Accounts(account_id),
  assigned_to INT REFERENCES Accounts(account_id),
  ...
);

Non mi piace includere il nome della tabella nel nome della colonna. Evito anche l'obbligo "id" come nome della colonna chiave primaria in ogni tabella.

Answer 2

Sono d'accordo con te. Mettendo queste informazioni nel nome della colonna si sente la pessima idiozia della Notazione ungherese dei primi giorni di Windows.

Answer 3

Ho sposato la maggior parte delle idee qui proposte negli ultimi vent'anni che ho sviluppato con database SQL, sono imbarazzato nel dire. La maggior parte di loro ha prodotto pochi o nessuno dei benefici previsti ed è stata col senno di poi, un dolore al collo.

Ogni volta che ho trascorso più di qualche ora con uno schema, ho acquisito abbastanza rapidamente familiarità con le tabelle più importanti e le loro colonne. Dopo alcuni mesi, avrei praticamente tutto in testa.

Per chi è tutta questa spiegazione? Qualcuno che trascorre solo pochi minuti con il design non farà comunque nulla di serio. Qualcuno che ha intenzione di lavorarci a lungo lo imparerà se hai nominato le tue colonne in sanscrito.

Ignorando le chiavi primarie composte, non vedo perché qualcosa di semplice come " id " non basterà per una chiave primaria e " _id " per le chiavi esterne.

Quindi una tipica condizione di join diventa customer.id = order.customer_id .

Laddove esiste più di un'associazione tra due tabelle, sarei propenso a utilizzare l'associazione anziché il nome della tabella, quindi forse "parent_id" e " child_id " anziché " parent_person_id " etc

Answer 4

Uso solo il tablename con un suffisso Id per la chiave primaria, ad es. CustomerId e le chiavi esterne che fanno riferimento a quello di altre tabelle verrebbero anche chiamate CustomerId. Quando fai riferimento nell'applicazione diventa evidente la tabella dalle proprietà dell'oggetto, ad es. Customer.TelephoneNumber, Customer.CustomerId, ecc.

Answer 5

Ho usato " fk_ " sul front-end di qualsiasi chiave esterna per un tavolo principalmente perché mi ha aiutato a mantenerlo dritto durante lo sviluppo del DB per un progetto nel mio negozio. Non avendo svolto alcun lavoro di DB in passato, questo mi ha aiutato. Col senno di poi, forse non avevo bisogno di farlo, ma c'erano tre personaggi apposti su alcuni nomi di colonna, quindi non ho sudato.

Essendo un nuovo arrivato nella scrittura di app DB, potrei aver preso alcune decisioni che farebbero rabbrividire uno sviluppatore DB esperto, ma non sono sicuro che la cosa chiave esterna sia davvero un grosso problema. Ancora una volta, immagino che sia una differenza nel punto di vista su questo problema e prenderò sicuramente quello che hai scritto e lo cogiterò su di esso.

Buona!

Answer 6

Sono d'accordo con te - adotto un approccio diverso che ho visto raccomandato in molti ambienti aziendali:

Colonne di nome nel formato NomeDecampoCampo , quindi se avessi una tabella Clienti e Nome utente fosse uno dei miei campi, il campo verrebbe chiamato CustomerUserName. Ciò significa che se avessi un'altra tabella chiamata Invoice e il nome utente del cliente fosse una chiave esterna, la chiamerei InvoiceCustomerUserName e quando la riferivo la chiamerei Invoice.CustomerUserName, che mi indica immediatamente in quale tabella si trova.

Inoltre, questa denominazione ti aiuta a tenere traccia delle tabelle da cui provengono le colonne quando esegui il joiining.

Uso solo FK_ e PK_ nei nomi ATTUALI delle chiavi esterne e primarie nel DBMS.