Qual è un modo efficace per etichettare le colonne in un database?

Ho usato per etichettare le colonne nei miei database in questo modo:

user_id
user_name
user_password_hash

Per evitare conflitti quando mi univo a due tabelle, ma poi ho imparato qualcosa in più su come alias le tabelle e ho smesso di farlo.

Qual è un modo efficace per etichettare le colonne in un database? Perché?

Nel tuo caso, l'utente del prefisso è ridondante. Noi (gli sviluppatori responsabili) sappiamo che questo è l'utente della tabella, quindi perché aggiungere il user_prefisso davanti a ogni campo?

Quello che ti suggerirei è di farlo con un approccio più naturale.

Quali sono le caratteristiche di una persona: cognome, nome, data di nascita, nazionalità, ecc ...

Quali sono le caratteristiche di un'auto: modello, anno, colore, energia, ecc ...

La tua colonna dovrebbe essere nominata il più naturale possibile, renderebbe lo schema più chiaro per tutti, per te e per quelli che ti seguono. Questa è anche chiamata fase di manutenzione e qualsiasi cosa tu possa fare per facilitare la manutenzione di solito vale la pena.

Oltre al commento di Spredzy, etichetta le tue chiavi primarie lo stesso (ID) in modo che quando scrivi query al volo, puoi facilmente richiamare (u.ID = c.ID) invece di dover cercare "Was countryID , country_ID, Countries_ID, CountriesID,? "

Non potrei essere più d'accordo con l'addendum di David Hall all'eccellente risposta di Spredzy. Semplice e naturale è la strada da percorrere. La confusione delle tabelle non dovrebbe essere un problema se anche le tabelle vengono denominate naturalmente.

Non ha senso avere utenti.user_id e cars.car_id quando potresti avere users.id e cars.id

Direi che in uno schema di database, ogni colonna dovrebbe avere un nome univoco, tra le tabelle. Ci sono diverse ragioni per questo:

• Da un punto di vista della modellazione: inizi con una zuppa di attributi e la normalizzi in tabelle. Nel tempo, potresti denormalizzare o normalizzare ulteriormente o introdurre viste o viste materializzate o introdurre nuove tabelle. Questo non è mai un problema se tutti i nomi delle colonne sono univoci.

• È possibile utilizzare questa sintassi join: a JOIN b USING (a_id) JOIN c USING (a_id). Molto conveniente e aiuta anche con il punto seguente.

• Se esegui query con molti join o crei viste materializzate SELECT *, non avrai mai (beh, forse raramente) un conflitto. Pensate a unirsi person.name, product.name, country.name, ecc Urgh.

• In generale, se hai grandi domande, è difficile tenere traccia di ciò che idsignifica ovunque.

Vediamo, con il tuo esempio sarà simile a questo:

USERS
----
id
username,
password
registration_date

Uso il nome della tabella in maiuscolo. Questo mi permette di identificare facilmente la tabella. Le colonne che ho appena nominato sono ognuna per ciò che rappresenta. Cerco di non usare numeri o includere alcun prefisso o suffisso con esso. Questo renderà le query completamente semplici e piuttosto semplici.

A proposito, penso che dovresti trovare lo stile che ti piace e attenersi ad esso. Se lo cambi spesso, avrai uno schema DB più messier.

Come gli altri, ti consiglio di non includere il nome della tabella come parte della colonna. A meno che tu non abbia centinaia di tabelle tutte con nomi di colonna per lo più simili: se hai più dozzine di tabelle tutte con una colonna denominata ID, allora tutte le prefissi con il nome della tabella.

Di recente ho lasciato un'azienda in cui uno degli sviluppatori preferiva aggiungere il prefisso alle colonne chiave primaria e chiave esterna con pk e fk. Ciò portò ad alcune abominazioni in cui le colonne iniziavano con pkfk (di solito una chiave primaria composita basata su 2 colonne, di cui una colonna era una chiave esterna per un'altra tabella).

Sto lavorando in un ambiente in cui ogni nome di colonna inizia con un prefisso derivato dal nome della tabella, non è una mia invenzione, ma ne sono abbastanza contento.

Idealmente i nomi delle colonne sono univoci su tutte le tabelle del database.

Alcune osservazioni:

• abbiamo solo bisogno di alias di tabella, quando le tabelle vengono unite più volte in un'istruzione select
• impedisce alcuni errori durante la copia di frammenti di codice, poiché i nomi delle colonne devono essere adattati al nome della tabella
• aiuta a mostrare a quale tabella punta una colonna chiave esterna

Idee generali: La più importante è la coerenza di ciascuna convenzione di denominazione: - singolare o plurale (ok che si applica alle tabelle e non alle colonne) - identifica le chiavi primarie ed esterne (costruiscono la struttura rispetto al contenuto del database) - sii coerente quando memorizzi stringhe e una breve variante della stessa stringa - sii coerente con flag, stato ecc.

Concordo con la risposta di Spredzy ma aggiungerei che per preferenza preferirei camelCase invece di under_score.

firstName, lastName ecc.

Nel caso di Oracle, ti consigliamo di non nominare le colonne 'id' o 'name' o qualcosa di generico.

Il problema è che per impostazione predefinita nelle versioni precedenti , Oracle tenterà di unire le tabelle in base a nomi di colonna simili, quindi se ho dato un nome tutto corretto, ho anche finito per specificare la clausola di join predefinita tra le mie tabelle.

Ma anche se si sta non utilizzando Oracle, non scegliendo nomi che appaiono in più tabelle, ma significa anche che non si devono poi passare attraverso la briga di aliasing ogni volta che dovete fare un selezionare tra due tabelle:

SELECT
  instrument.name as instrument_name,
  instrument.abbr as instrument_abbr,
  source.name     as source_name,
  source.abbr     as source_abbr,
  ...
FROM ...

Quindi, se le selezioni su più tabelle sono la norma, i nomi di colonne più lunghi ti risparmiano la digitazione. (se stai usando solo una tabella alla volta ... hai davvero bisogno di un database relazionale?)

... e il salvataggio della digitazione ci porta a un altro problema in Oracle - almeno in 8i (la versione corrente quando ho seguito i corsi di Oracle SQL Tuning e Data Modeling) la memorizzazione nella cache dei piani di esecuzione si basa solo sui primi così tanti caratteri del query (non ricordi il valore esatto ... 1024?), quindi se hai query che variano solo di qualcosa fino alla fine della clausola where e un elenco davvero lungo di colonne che stai estraendo, tu può incorrere in un hit delle prestazioni in quanto non è possibile memorizzare correttamente nella cache il piano di esecuzione.

Oracle aveva una guida sulla selezione di quelli che sostengono che fossero nomi di tabelle e colonne, che in pratica è una guida per la rimozione di lettere fino a circa 5-8 caratteri, ma non me ne è mai importato molto.

...

Dato che le cose vanno diversamente:

• le colonne sono sempre singolari (le tabelle sono sempre plurali)
• tutti i nomi sono in minuscolo, nel caso in cui ci sia qualcosa che distingue tra maiuscole e minuscole
• come risultato di quanto sopra, utilizzare i trattini bassi anziché la custodia del cammello.

aggiornamento : per coloro che non hanno familiarità con il comportamento dei join di Oracle, vedere l'ultimo esempio su Mastering Oracle SQL: Condizioni di join , dove menziona:

Quello che è successo? Il motivo sta nel fatto che, oltre a supplier_id, queste due tabelle hanno un'altra coppia di colonne con un nome comune. Quella colonna è il nome. Pertanto, quando si richiede un join naturale tra il fornitore e le tabelle delle parti, il join ha luogo non solo equiparando la colonna supplier_id delle due tabelle, ma anche la colonna del nome delle due tabelle viene equiparata. Poiché, il nome del fornitore non corrisponde al nome della parte dello stesso fornitore, la query non restituisce righe.

Sotto "vecchia sintassi del join" (8i e precedenti), "NATURAL JOIN" era il comportamento del join predefinito e credo che lo sia ancora se non si specifica una condizione di join. Una volta che 'NATURAL JOIN' era un'opzione ufficiale in 9i, la raccomandazione generale era di non usarla , perché una cattiva denominazione delle colonne può rovinarti, che è il mio che sto sostenendo per i nomi di buone colonne.

1. Non usare mai virgolette "perché, in tal modo, si ignora la piegatura nativa del case del database. Le specifiche SQL richiedono che tutti gli identificatori siano piegati in maiuscolo. Alcuni database, come PostgreSQL, li piegano in minuscolo. Se non viene citato nulla, funzionerà in tutti i database e potranno piegarli alla specifica o al valore predefinito specifico di rdbms.
2. Usa un under_score ( _), perché come sopra - non dovresti usare camelCase.

3. utilizzare {entity}_idper ID (e chiavi esterne che puntano a tali ID). Perché allora puoi usare la USINGclausola. I nomi delle chiavi univoci a livello globale utilizzati nelle condizioni di join sono una convenzione stabilita nelle specifiche.

   SELECT *
   FROM employee
   INNER JOIN department
     USING (department_id);
   
     -- compare to
     ON employee.department_id = department.department_id;