Denominazione delle colonne ID nelle tabelle del database

Mi chiedevo l'opinione delle persone sulla denominazione delle colonne ID nelle tabelle del database.

Se ho una tabella chiamata Fatture con una chiave primaria di una colonna Identity, chiamerei quella colonna InvoiceID in modo da non entrare in conflitto con altre tabelle ed è ovvio di cosa si tratta.

Dove sto lavorando attualmente hanno chiamato ID di tutte le colonne ID.

Quindi farebbero quanto segue:

Select  
    i.ID 
,   il.ID 
From
    Invoices i
    Left Join InvoiceLines il
        on i.ID = il.InvoiceID

Ora, vedo alcuni problemi qui:
1. Dovresti
creare un alias per le colonne sulla selezione 2. ID = InvoiceID non si adatta al mio cervello
3. Se non hai alias le tabelle e hai fatto riferimento a InvoiceID è ovvio quale tabella è su?

Quali sono i pensieri di altre persone sull'argomento?

L'ID è un Antipattern SQL. Vedi http://www.amazon.com/s/ref=nb_sb_ss_i_1_5?url=search-alias%3Dstripbooks&field-keywords=sql+antipatterns&sprefix=sql+a

Se hai molte tabelle con ID come ID, rendi i rapporti molto più difficili. Nasconde il significato e rende le query complesse più difficili da leggere, oltre a richiedere l'utilizzo di alias per differenziare il report stesso.

Inoltre, se qualcuno è così sciocco da usare un join naturale in un database in cui sono disponibili, ti unirai ai record sbagliati.

Se desideri utilizzare la sintassi USING consentita da alcuni db, non puoi farlo se usi ID.

Se usi l'ID puoi facilmente finire con un join sbagliato se ti capita di copiare la sintassi del join (non dirmi che nessuno lo fa mai!) E dimenticare di cambiare l'alias nella condizione di join.

Quindi ora hai

select t1.field1, t2.field2, t3.field3
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t1.id = t3.table2id

quando intendevi

select t1.field1, t2.field2, t3.field3 
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t2.id = t3.table2id

Se usi tablenameID come campo id, questo tipo di errore accidentale è molto meno probabile e molto più facile da trovare.

Ho sempre preferito ID a TableName + ID per la colonna id e quindi TableName + ID per una chiave esterna. In questo modo tutte le tabelle hanno lo stesso nome per il campo id e non c'è una descrizione ridondante. Questo mi sembra più semplice perché tutte le tabelle hanno lo stesso nome di campo della chiave primaria.

Per quanto riguarda l'unione di tabelle e non sapere quale campo Id appartiene a quale tabella, a mio parere la query dovrebbe essere scritta per gestire questa situazione. Dove lavoro, anteponiamo sempre i campi che usiamo in un'istruzione con l'alias table / table.

Negli ultimi tempi c'è stata una litigata tra nerd proprio su questa cosa in mia compagnia. L'avvento di LINQ ha reso il modello tablename + ID ridondante ancora più ovviamente sciocco ai miei occhi. Penso che le persone più ragionevoli diranno che se stai scrivendo a mano il tuo SQL in modo tale da dover specificare i nomi delle tabelle per differenziare gli FK, allora non è solo un risparmio sulla digitazione, ma aggiunge chiarezza al tuo SQL da usare solo l'ID in quanto puoi vedere chiaramente quale è il PK e quale è l' FK .

Per esempio

FROM Employees e LEFT JOIN Customers c ON e.ID = c.EmployeeID

mi dice non solo che i due sono collegati, ma che è il PK e che è l' FK . Mentre nel vecchio stile sei costretto a guardare o sperare che siano stati nominati bene.

Usiamo InvoiceID, no ID. Rende le query più leggibili: quando vedi IDda solo potrebbe significare qualsiasi cosa, specialmente quando alias la tabella i.

Sono d'accordo con Keven e poche altre persone qui sul fatto che il PK per una tabella dovrebbe essere semplicemente Id e le chiavi esterne elencano OtherTable + Id.

Tuttavia, vorrei aggiungere una ragione che recentemente ha dato più peso a questo argomento.

Nella mia posizione attuale stiamo impiegando il framework delle entità utilizzando la generazione POCO. Utilizzando la convenzione di denominazione standard di Id, il PK consente l'ereditarietà di una classe base poco con convalida e tale per le tabelle che condividono un insieme di nomi di colonna comuni. L'utilizzo di Tablename + Id come PK per ciascuna di queste tabelle distrugge la capacità di utilizzare una classe base per queste.

Solo alcuni spunti di riflessione.

La mia preferenza è anche ID per la chiave primaria e TableNameID per la chiave esterna. Mi piace anche avere una colonna "nome" nella maggior parte delle tabelle in cui tengo l'identificatore leggibile dall'utente (es. Nome :-)) della voce. Questa struttura offre una grande flessibilità nell'applicazione stessa, posso gestire tabelle in massa, allo stesso modo. Questa è una cosa molto potente. Di solito un software OO è costruito sopra il database, ma il set di strumenti OO non può essere applicato perché il db stesso non lo consente. Avere l'ID e il nome delle colonne non è ancora molto buono, ma è un passaggio.

Seleziona
i.ID, il.ID da Fatture i Left Join InvoiceLines il su i.ID = il.InvoiceID

Perché non posso farlo?

Select  
    Invoices.ID 
,   InvoiceLines.ID 
From
    Invoices
    Left Join InvoiceLines
        on Invoices.ID = InvoiceLines.InvoiceID

Secondo me questo è molto leggibile e semplice. Denominare le variabili come i e il è una scelta sbagliata in generale.

Non è molto importante, è probabile che tu incorra in problemi simili in tutte le convenzioni di denominazione.

Ma è importante essere coerenti in modo da non dover guardare le definizioni della tabella ogni volta che scrivi una query.

Ho appena iniziato a lavorare in un posto che utilizza solo "ID" (nelle tabelle principali, referenziato da TableNameID nelle chiavi esterne), e ho già riscontrato DUE problemi di produzione direttamente causati da esso.

In un caso, la query ha utilizzato "... dove ID in (SELEZIONA ID DA Altra tabella ..." invece di "... dove ID in (SELEZIONA ID transitorio da altra tabella ...".

Qualcuno può onestamente dire che non sarebbe stato molto più facile individuare se fossero stati usati nomi completi e coerenti dove l'istruzione sbagliata avrebbe letto "... dove TransID in (SELECT OtherTableID from OtherTable ..."? Non credo così.

L'altro problema si verifica durante il refactoring del codice. Se usi una tabella temporanea mentre in precedenza la query usciva da una tabella principale, il vecchio codice legge "... dbo.MyFunction (t.ID) ..." e se non è cambiato ma "t" ora si riferisce a un temp table invece della tabella core, non ottieni nemmeno un errore - solo risultati errati.

Se la generazione di errori non necessari è un obiettivo (forse alcune persone non hanno abbastanza lavoro?), Allora questo tipo di convenzione di denominazione è ottimo. Altrimenti una denominazione coerente è la strada da percorrere.

Per motivi di semplicità, la maggior parte delle persone nomina la colonna nell'ID tabella. Se ha un riferimento a una chiave esterna su un'altra tabella, lo chiamano esplicitamente InvoiceID (per usare il tuo esempio) nel caso dei join, stai comunque creando un alias della tabella, quindi l'ID inv.esplicito è ancora più semplice di inv.InvoiceID

Io personalmente preferisco (come è stato detto in precedenza) la Table.ID per la PK e TableID per l' FK . Anche (per favore non spararmi) Microsoft Access lo consiglia.

TUTTAVIA, so ANCHE per certo che alcuni strumenti di generazione favoriscono il TableID per PK perché tendono a collegare tutti i nomi delle colonne che contengono "ID" nella parola, INCLUSO ID !!!

Anche il progettista di query lo fa su Microsoft SQL Server (e per ogni query che crei, finisci per strappare tutte le relazioni appena create non necessarie su tutte le tabelle sull'ID colonna)

COSÌ, per quanto il mio disturbo ossessivo compulsivo interno lo odia, mi muovo con la convenzione TableID . Ricordiamo che si chiama Data BASE , in quanto sarà la base per molte molte applicazioni a venire, si spera. E tutte le tecnologie dovrebbero beneficiare di uno schema ben normalizzato con una descrizione chiara.

Inutile dire che traccio la mia linea quando le persone iniziano a usare TableName, TableDescription e simili. A mio parere, le convenzioni dovrebbero fare quanto segue:

• Nome tabella: pluralizzato. Ex. Dipendenti

• Alias ​​tabella: nome completo della tabella, singolarizzato. Ex.

  SELECT Employee.*, eMail.Address
  FROM Employees AS Employee LEFT JOIN eMails as eMail on Employee.eMailID = eMail.eMailID -- I would sure like it to just have the eMail.ID here.... but oh well

[Aggiornare]

Inoltre, ci sono alcuni post validi in questo thread sulle colonne duplicate a causa del "tipo di relazione" o del ruolo. Ad esempio, se un negozio ha un EmployeeID , questo mi dice squat. Quindi a volte faccio qualcosa come Store.EmployeeID_Manager . Certo è un po 'più grande, ma almeno le persone non impazziranno cercando di trovare la tabella ManagerID o cosa ci sta facendo EmployeeID . Quando l'interrogazione è DOVE lo semplificherei come: SELEZIONA EmployeeID_Manager come ManagerID FROM Store

Venendo a questo dalla prospettiva di un dizionario di dati formale, chiamerei l'elemento dati invoice_ID. In generale, il nome di un elemento dati sarà univoco nel dizionario dati e idealmente avrà lo stesso nome ovunque, sebbene a volte potrebbero essere richiesti termini qualificanti aggiuntivi in ​​base al contesto, ad esempio l'elemento dati denominato employee_IDpotrebbe essere utilizzato due volte nell'organigramma e quindi qualificato come supervisor_employee_IDe subordinate_employee_IDrispettivamente.

Ovviamente, le convenzioni di denominazione sono soggettive e una questione di stile. Trovo che le linee guida ISO / IEC 11179 siano un utile punto di partenza.

Per il DBMS, vedo le tabelle come raccolte di entità (eccetto quelle che contengono sempre e solo una riga, ad esempio tabella cofig, tabella di costanti, ecc.) Ad esempio, la tabella in cui my employee_IDè la chiave sarebbe denominata Personnel. Quindi subito la TableNameIDconvenzione non funziona per me.

Ho visto lo TableName.ID=PK TableNameID=FKstile utilizzato su modelli di dati di grandi dimensioni e devo dire che lo trovo leggermente confuso: preferisco di gran lunga che il nome di un identificatore sia lo stesso dappertutto, ad esempio non cambia il nome in base alla tabella in cui appare. Qualcosa da notare è lo stile di cui sopra sembra essere utilizzato nei negozi che aggiungono una IDENTITYcolonna (incremento automatico) a ogni tabella evitando le chiavi naturali e composte nelle chiavi esterne. Questi negozi tendono a non avere dizionari di dati formali né costruire da modelli di dati. Ancora una volta, questa è solo una questione di stile e una a cui non mi abbono personalmente. Quindi, alla fine, non è per me.

Detto questo, posso vedere un caso per cui a volte si elimina il qualificatore dal nome della colonna quando il nome della tabella fornisce un contesto per farlo, ad esempio l'elemento denominato employee_last_namepuò diventare semplicemente last_namenella Personneltabella. La logica qui è che il dominio è 'cognomi delle persone' ed è più probabile che venga modificato UNIONcon last_namecolonne di altre tabelle piuttosto che essere usato come chiave esterna in un'altra tabella, ma poi di nuovo ... potrei semplicemente cambiare idea, a volte non puoi mai dirlo. Questo è il punto: la modellazione dei dati è in parte arte, in parte scienza.

Penso che tu possa usare qualsiasi cosa per l '"ID" purché tu sia coerente. È importante includere il nome della tabella. Suggerirei di utilizzare uno strumento di modellazione come Erwin per applicare le convenzioni e gli standard di denominazione in modo che durante la scrittura di query sia facile comprendere le relazioni che possono esistere tra le tabelle.

Quello che intendo con la prima affermazione è che invece di ID puoi usare qualcos'altro come "recno". Quindi questa tabella avrebbe un PK di invoice_recno e così via.

Salute, Ben

Il mio voto è per InvoiceID per l'ID tabella. Uso anche la stessa convenzione di denominazione quando viene utilizzata come chiave esterna e utilizzo nomi alias intelligenti nelle query.

 Select Invoice.InvoiceID, Lines.InvoiceLine, Customer.OrgName
 From Invoices Invoice
 Join InvoiceLines Lines on Lines.InvoiceID = Invoice.InvoiceID
 Join Customers Customer on Customer.CustomerID = Invoice.CustomerID

Certo, è più lungo di altri esempi. Ma sorridi. Questo è per i posteri e un giorno, un povero programmatore junior dovrà modificare il tuo capolavoro. In questo esempio non c'è ambiguità e man mano che vengono aggiunte tabelle aggiuntive alla query, sarai grato per la verbosità.

Per il nome della colonna nel database, utilizzerei "InvoiceID".

Se copio i campi in una struttura senza nome tramite LINQ, posso chiamarlo "ID" lì, se è l'unico ID nella struttura.

Se la colonna NON verrà utilizzata in una chiave esterna, in modo che venga utilizzata solo per identificare in modo univoco una riga per la modifica, la modifica o la cancellazione, la chiamerò "PK".

Se assegni a ciascuna chiave un nome univoco, ad esempio "invoices.invoice_id" invece di "invoices.id", puoi utilizzare gli operatori "natural join" e "using" senza preoccupazioni. Per esempio

SELECT * FROM invoices NATURAL JOIN invoice_lines
SELECT * FROM invoices JOIN invoice_lines USING (invoice_id)

invece di

SELECT * from invoices JOIN invoice_lines
    ON invoices.id = invoice_lines.invoice_id

SQL è abbastanza dettagliato senza renderlo più dettagliato.

Quello che faccio per mantenere le cose coerenti per me stesso (dove una tabella ha una chiave primaria a colonna singola usata come ID) è nominare la chiave primaria della tabella Table_pk. Ovunque ho una chiave esterna che punta alla chiave primaria di quella tabella, chiamo la colonna PrimaryKeyTable_fk. In questo modo so che se ho un Customer_pknella mia tabella Clienti e uno Customer_fknella mia tabella Ordini, so che la tabella Ordine si riferisce a una voce nella tabella Clienti.

Per me, questo ha senso soprattutto per i join in cui penso che sia più facile da leggere.

SELECT * 
FROM Customer AS c
    INNER JOIN Order AS c ON c.Customer_pk = o.Customer_fk

FWIW, il nostro nuovo standard (che cambia, uh, intendo "evolve", con ogni nuovo progetto) è:

• Nomi dei campi del database in minuscolo
• Nomi di tabella maiuscoli
• Usa i caratteri di sottolineatura per separare le parole nel nome del campo - convertili in maiuscolo e minuscolo Pascal nel codice.
• pk_ prefisso significa chiave primaria
• _id suffisso indica un numero intero, ID con incremento automatico
• fk_ prefisso significa chiave esterna (nessun suffisso necessario)
• _VW suffisso per le visualizzazioni
• is_ prefisso per booleani

Quindi, una tabella denominata nomi potrebbero avere i campi pk_name_id, first_name, last_name, is_alive,e fk_companyed una vista chiamata LIVING_CUSTOMERS_VW, definito come:

SELEZIONA first_name, last_name
DA CONTACT.NAMES
WHERE (is_alive = 'True')

Come altri hanno già detto, tuttavia, quasi tutti gli schemi funzioneranno purché siano coerenti e non offuscino inutilmente i tuoi significati.

Sono assolutamente d'accordo con l'inclusione del nome della tabella nel nome del campo ID, esattamente per i motivi che fornisci. Generalmente, questo è l'unico campo in cui includerei il nome della tabella.

Odio il semplice nome di identificazione. Preferisco fortemente utilizzare sempre il invoice_id o una sua variante. So sempre quale tabella è la tabella autorevole per l'id quando ne ho bisogno, ma questo mi confonde

SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceID = inv.ID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceLineID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceLineID = inv.ID 

La cosa peggiore è il mix di cui parli, totalmente confuso. Ho dovuto lavorare con un database in cui quasi sempre era foo_id tranne che in uno degli ID più utilizzati. Quello era un inferno totale.

Preferisco DomainName || "ID". (ad es. DomainName + ID)

DomainName è spesso, ma non sempre, lo stesso di TableName.

Il problema con l'ID da solo è che non scala verso l'alto. Una volta che hai circa 200 tabelle, ciascuna con una prima colonna denominata ID, i dati iniziano a sembrare tutti uguali. Se qualifichi sempre ID con il nome della tabella, ciò aiuta un po ', ma non molto.

DomainName e ID possono essere utilizzati per denominare sia chiavi esterne che chiavi primarie. Quando le chiavi straniere prendono il nome dalla colonna a cui fanno riferimento, ciò può essere di aiuto mnemonico. Formalmente, non è necessario legare il nome di una chiave esterna alla chiave a cui fa riferimento, poiché il vincolo di integrità referenziale stabilirà il riferimento. Ma è terribilmente utile quando si tratta di leggere query e aggiornamenti.

Occasionalmente, DomainName || Impossibile utilizzare "ID" perché nella stessa tabella sarebbero presenti due colonne con lo stesso nome. Esempio: Employees.EmployeeID e Employees.SupervisorID. In questi casi, utilizzo RoleName || "ID", come nell'esempio.

Ultimo ma non meno importante, uso chiavi naturali piuttosto che sintetiche quando possibile. Ci sono situazioni in cui le chiavi naturali non sono disponibili o inaffidabili, ma ci sono molte situazioni in cui la chiave naturale è la scelta giusta. In quei casi, ho lasciato che la chiave naturale assumesse il nome che avrebbe naturalmente. Questo nome spesso non contiene nemmeno le lettere "ID". Esempio: OrderNo dove No è ​​l'abbreviazione di "Number".

Per ogni tabella scelgo una scorciatoia con lettere ad albero (es. Employees => Emp)

In questo modo una chiave primaria numerica automatica diventa nkEmp .

È breve, unico nell'intero database e conosco esattamente le sue proprietà a colpo d'occhio.

Mantengo gli stessi nomi in SQL e in tutti i linguaggi che uso (principalmente C #, Javascript, VB6).

Vedere le convenzioni di denominazione del sito Interakt per un sistema ben congegnato di denominazione di tabelle e colonne. Il metodo utilizza un suffisso per ciascuna tabella ( _prdper una tabella di prodotti o _ctgper una tabella di categorie) e lo aggiunge a ciascuna colonna in una determinata tabella. Quindi la colonna Identity per la tabella dei prodotti sarebbe id_prded è quindi unica nel database.

Fanno un ulteriore passo avanti per aiutare a comprendere le chiavi esterne: la chiave esterna nella tabella del prodotto che si riferisce alla tabella delle categorie sarebbe in idctg_prdmodo che sia ovvio a quale tabella appartiene ( _prdsuffisso) ea quale tabella si riferisce (categoria) .

I vantaggi sono che non vi sono ambiguità con le colonne Identity in tabelle diverse e che è possibile individuare a colpo d'occhio a quali colonne fa riferimento una query in base ai nomi delle colonne.

vedere anche la convenzione di denominazione chiave primaria / chiave esterna

È possibile utilizzare la seguente convenzione di denominazione. Ha i suoi difetti ma risolve i tuoi problemi particolari.

1. Usa soprannomi brevi (3-4 caratteri) per i nomi delle tabelle, ad esempio Invoice - inv, InvoiceLines -invl
2. Nome le colonne della tabella usando quei soprannomi, vale a dire inv_id,invl_id
3. Per le colonne di riferimento utilizzare invl_inv_idper i nomi.

in questo modo potresti dire

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id