Mi chiedo quale sia la pratica migliore per denominare le chiavi primarie/uniche in un database con molte tabelle. Dovresti sempre chiamare la chiave primaria di ogni tabella id o non avere un campo id in ogni tabella e solo nominare ciascuno di essi something1_id, something2_id, ecc.?Denominazione delle chiavi primarie "id" vs "something_id" in SQL
Qualsiasi cosa tu faccia, scegli l'uno o l'altro e rispetta lo standard. Ci sono pro e contro per ciascuno.
Preferisco SomethingID ma altre persone preferiscono solo ID. Nel sistema con cui lavoro ci sono oltre un migliaio di tavoli e il fatto che PK e FK abbiano gli stessi nomi identici semplifica le cose.
hi KM, grazie. Quindi, purché non ci sia un modo chiaramente superiore, penso che rimarrò con 'somethingID'. –
@tim peterson, tutto dipende da come si usa SQL e cosa funziona per voi. Il punto chiave della query è ottenere rapidamente le informazioni indietro e il nome della colonna non influirà su questo, l'utilizzo dell'indice lo farà. –
La cosa peggiore in assoluto è DB che utilizzano più di una convenzione di denominazione. Ho lavorato su un sistema che utilizzava 4 diverse convenzioni di denominazione per i PK surrogati. –
È una preferenza personale. Alla fine della giornata non fa assolutamente differenza. Personalmente preferisco usare solo Id come trovo riferentesi al campo (diciamo il tavolo Customer e il campo Id) Customer.CustomerId per essere ingombrante, dove Customer.Id sembra avere più senso.
Suggerirei di utilizzare un'abbreviazione per nomi lunghi e utilizzare (qualcosa) Id (come user_id) per tabelle regolari. Quindi per il tavolo customer_company_relation_metadata utilizzare ccm_id. Ma il suo bel da utilizzare id così
Si prega di non usare le abbreviazioni in questo contesto, solo di confondere il codice ed è meno leggibile per i nuovi (e) membri del team/codice (e anche per te stesso dopo una pausa). Buon materiale di lettura: http://programmers.stackexchange.com/a/24083 – Styxxy
@Styxxy Ho trovato che sono il modo più utile tra avere nomi di colonne lunghe (che sono fastidiosi in query più lunghe) e dover usare 'utente. id' tutto il tempo. Ma è ovviamente una questione di gusti. –
I nomi molto lunghi possono essere abbreviati, forse.Non lo userei comunque per l'utente (quali sono quelle 2 lettere se paghi molto in leggibilità?). In effetti è in parte la tua preferenza, ma abbreviare abbreviare è semplicemente sbagliato (non vorrei mantenere il codice in questo modo). PS: Se hai un editor decente, anche i nomi lunghi non dovrebbero avere importanza. – Styxxy
id è solo una convenzione vantaggiosa - è possibile chiamare il nulla campo fino a quando si dichiara come un campo chiave.
La preimpostazione dell'ID con un contesto pertinente può essere utile quando si tratta di leggere e scrivere il codice, e migliora in particolare la leggibilità quando si uniscono dati da più tabelle e chiavi esterne.
(* Solo un pensiero perché la tua risposta ha attirato la mia attenzione e stavo pensando alla programmazione su un'interfaccia. *) Vero, e sono d'accordo, ma l'approccio 'id' traduce meglio i record delle tabelle negli oggetti, specialmente se hai un super astratto -class con una proprietà 'id'. Se fai ciò che suggerisci (cosa che anch'io faccio), devi anche gestire i vari campi e proprietà 'blahId' quando si mappano i record della tabella in oggetti. Ciò sarebbe vero per le chiavi esterne che vengono comunque convertite in proprietà dell'oggetto, ma almeno la super-classe astratta potrebbe avere solo una proprietà semplice chiamata id. –
Può avere comunque una proprietà 'id', ma il tuo codice sarebbe più coerente orizzontalmente tra le super-classi astratte se usassimo' id', specialmente quando assegniamo il valore del campo 'id' alla proprietà' id'. La chiarezza del database potrebbe risentirne, ma ciò può essere mitigato fornendo i nomi delle chiavi straniere "blahId". Questi nomi penetreranno negli oggetti, ma sarai in grado di sapere cosa è cosa. –
E è una questione di preferenza; tuttavia, c'è un vantaggio nell'usare (qualcosa) ID in quei nomi di colonne che diventano meno ambigui quando si fanno join tra tabelle.
sì, grazie sono d'accordo, questa domanda è nata perché ho scritto sempre più JOINs ... –
C'è un vantaggio per entrambi quando si partecipa. Preferisco 'id' per il nome della colonna dato che elencerò i nomi delle tabelle prima delle colonne in * all * join in ogni caso, quindi' tablename_id' o qualcosa di simile è solo una specificità extra non necessaria. – 0b10011
@bfrohs: Sì, sono d'accordo includendo il nome della tabella nel nome della colonna ID implica un po 'più di digitazione. –
Ci sono mazzi di articoli là fuori, andare a controllare questo fuori ...
E, soprattutto, come detto sopra KM, sceglierne uno & bastone ad esso !!!! – larryr
'something_id' è ridondante quando si può usare' table.id' ovunque ... a meno che non sei mettere una chiave straniera. –
Mi sono sempre chiesto cosa pensa la gente dei pro e dei contro degli approcci – erikkallen
il problema della chiave esterna è il motivo per cui "ID" può essere fonte di confusione - perché è necessario creare una relazione con "somethingID" in una tabella diversa; stai creando relazioni su campi con nomi diversi. – niico