Esiste uno standard / convenzione per l'ordinamento di colonne nella definizione di una tabella del database?

Question

Esiste uno standard / convenzione su come ordinare le colonne nella definizione di una tabella di database e, in caso affermativo, qual è la motivazione per quello standard? (Pro / contro)

Ad esempio, la chiave primaria dovrebbe essere la prima colonna? Le chiavi esterne devono seguire direttamente la chiave primaria o devono essere posizionate all'estrema destra della tabella?

Se c'è una differenza tra le convenzioni per diversi DBMS, il DBMS in questo caso è Microsoft SQL Server 2005.

Grazie / Erik

Answer 1

Non sono a conoscenza di alcuno standard, ma il modo in cui strutturiamo le nostre colonne è

1. Chiave / e primaria / e
2. Eventuali chiavi esterne
3. Dati

Le nostre colonne di dati grandi , come i commenti, vengono messe alla fine. Semplifica la visualizzazione di quanti più dati possibili nell'analizzatore di query senza dover scorrere verso destra.

Answer 2

Strutturo sempre le mie tabelle in questo modo:

1. Chiave / e primaria / e
2. colonne "Tracciamento" (DateModified, ModifiedBy e simili)
3. Eventuali chiavi esterne
4. Dati

Answer 3

Non sono sicuro delle convenzioni impostate, ma inseriamo sempre la colonna ID / Chiave primaria come prima colonna della tabella. Suppongo sia solo perché rende più chiaro vedere il pk. Direi che segui anche quello con i campi FK ma dopo che non esiste uno standard reale, potresti farlo per tipo di dati?

Inoltre, questa non è una best practice definita, ma solo una scelta personale.

Answer 4

Nessuno di cui io sia a conoscenza. Puoi sempre riordinare le colonne durante una selezione, quindi non importa a meno che non ci sia qualche ottimizzazione davvero oscura che puoi fare su alcuni database ordinando le tue colonne in modo appropriato.

Answer 5

Non esiste uno standard ufficiale di cui io sia a conoscenza, ma la pratica normale è mettere prima la chiave primaria (di solito è un surrogato) e quindi raggruppare gli altri campi in base alla funzionalità. Quindi in una "persona" la tabella uno raggrupperebbe i campi contenenti i dati dell'indirizzo della persona insieme. Molte persone aggiungono FK, indici e altri vincoli al di fuori della definizione della tabella corretta.

Answer 6

mm .. Come so, non ci sono limiti. È solo una questione di chiarezza.

Answer 7

Sono d'accordo con la maggior parte dei post sopra, prima la chiave primaria (almeno). Il resto è preferenza personale. Se si dispone di uno standard, attenersi a tale standard.

Preferisco mantenere le colonne in modo abbastanza logico insieme. A volte una struttura di dati completamente normalizzata non è appropriata, quindi hai "entità minori" memorizzato nella stessa tabella (ovvero non rimuovere i NULL). Un esempio potrebbe essere i campi dell'indirizzo, o i diversi telefoni, telefoni cellulari, colonne del telefono di lavoro messi insieme.

L'esempio più eclatante che posso dare è COME NON FARLO. Se uno sviluppatore genera automaticamente uno schema e le colonne vengono create in ordine alfabetico (e persino il PK era nascosto nel mezzo della struttura della tabella), questo è PIÙ fastidioso.

Answer 8

Come da edoode: -

Primary key(s) 
'Tracking' columns (DateModified, ModifiedBy and such) 
Any foreign keys 
Data 

Inoltre

Fixed width 'not null' columns
Fixed width 'nullable' columns
Variable Width columns VARCHAR NVARCHAR etc.
CLOBS
BLOBS 

Ottieni un aumento delle prestazioni così piccolo e giovanile se attacchi le colonne che possono variare di lunghezza nella parte inferiore della tabella.