Da tempo abbiamo gli standard di codifica per il nostro codice .Net e sembrano esserci diverse fonti affidabili per idee su come applicarle che si evolvono nel tempo.
Mi piacerebbe essere in grado di mettere insieme alcuni standard per l'SQL che è stato scritto per l'uso dai nostri prodotti, ma non sembrano esserci risorse sul consenso per ciò che determina SQL ben scritto?
Nella mia esperienza, le cose principali che avrei cercato sarebbero:
Nome tabella e colonna: controlla se usi ID, riferimento o numero per colonne di tipo ID, singolari o plurali per nomi (i plurali sono comuni per i nomi di tabelle - ad es. COSE, singolari per i nomi di colonne - ad esempio THING_ID) . Per me le cose più importanti qui sono la coerenza che evita alle persone di perdere tempo (ad esempio non si trovano errori di battitura in cui qualcuno ha inserito THING come nome di una tabella perché si sa solo intuitivamente che i nomi delle tabelle non sono mai singolari).
Tutte le creazioni dovrebbero includere una caduta (condizionale sull'oggetto esistente) come parte del loro file. Potresti anche voler includere le autorizzazioni di concessione, fino a te.
Seleziona, aggiorna, inserisce ed elimina un nome di colonna, un nome di tabella e uno in cui clausola / ordina per clausola per riga in modo che possano essere facilmente commentati uno alla volta durante il debug.
Prefisso per tipi di oggetto in particolare dove potrebbero essere confusi (quindi v per la visualizzazione è il più importante). Non sono sicuro se si applica ancora, ma in passato era inefficiente per le stored procedure diverse dalle procedure di sistema per iniziare sp_. Probabilmente le migliori pratiche per differenziarle comunque usp_ era quello che ho usato più di recente.
Uno standard che indica come il nome di un trigger dovrebbe includere se è per update / insert / delete e la tabella a cui si applica. Non ho uno standard preferito, ma questa è un'informazione critica e deve essere facile da trovare.
Standard per la proprietà degli oggetti nelle versioni precedenti di SQL Server o lo schema in cui dovrebbe esistere per il 2005 e successivi. È una tua chiamata di cosa si tratta, ma non dovresti mai indovinare chi possiede qualcosa / dove vive) e dove possibile lo schema / proprietario dovrebbe essere incluso negli script CREATE per minimizzare la possibilità che venga creato in modo errato.
Un indicatore che chiunque usi SELECT * sarà fatto per bere una pinta della propria urina.
A meno che non ci sia una ragione davvero buona (che non include la pigrizia da parte tua), hai, applica e mantieni le relazioni chiave primaria / chiave esterna dall'inizio. Questo dopotutto è un database relazionale, non un file piatto e record orfani renderanno il vostro supporto un inferno di vita ad un certo punto. Inoltre, tieni presente che se non lo fai ora posso prometterti che non riuscirai mai a implementarlo dopo l'evento perché è 10 volte il lavoro una volta che hai dati (che sarà un po 'fottuto perché non hai mai forzato le relazioni correttamente).
Sono sicuro di aver perso qualcosa, ma per me sono quelli che in realtà offrono un vantaggio reale in un numero decente di situazioni.
Ma come per tutti gli standard, less is more. Più gli standard di codifica sono lunghi, meno è probabile che le persone li leggano e li usino. Una volta superato un paio di pagine ben distanziate inizia a cercare di eliminare le cose che non fanno realmente una differenza pratica nel mondo reale perché stai solo riducendo la possibilità che le persone ne facciano una parte.
EDIT: due correzioni - compresi gli schemi nella sezione ownership, rimuovendo un suggerimento errato sul conteggio (*) - vedi i commenti sotto.
there don't seem to be any resources out there on the consensus for what determines well written SQL
Questo perché non c'è consenso. A titolo di esempio, avrei avuto risposte diverse per almeno la metà degli articoli nell'elenco di Jon Hopkins, e in base alla quantità di dettagli sulla sua lista, è una ipotesi sicura che entrambi lavoriamo con i database per vivere.
Detto questo, uno standard di codifica è ancora una buona cosa da avere, e uno standard che tutti i membri del team comprendono e concorda è una cosa migliore, perché lo standard sarà più probabilmente seguito.
Oltre alla risposta di Jon Hopkins ...
Separa oggetti interni vs esterni
Per oggetti interni, rendili espliciti se "non predefinito"
Utilizza gli schemi per semplificare le autorizzazioni di denominazione +. Esempi:
Leggi altre domande sui tag coding-standards sql-server