Qualcuno può raccomandare standard di codifica per TSQL?

Da tempo abbiamo 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 essere utilizzato dai nostri prodotti, ma non sembrano esserci risorse sul consenso per ciò che determina l'SQL ben scritto?

Nella mia esperienza le cose principali che vorrei cercare sarebbero:

• Denominazione di tabelle e colonne: controlla se usi ID, riferimento o numero per colonne di tipo ID, singolari o plurali per nomi (i plurali sono comuni per i nomi delle tabelle, ad esempio THINGS, 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 ti imbatti in errori di battitura in cui qualcuno ha messo COSA come nome di tabella perché sai solo intuitivamente che i nomi di tabella non sono mai singolari).

• Tutte le creazioni dovrebbero includere una goccia (subordinata all'oggetto esistente) come parte del loro file. Potresti anche voler includere le autorizzazioni di concessione, a te.

• Selezioni, aggiornamenti, inserimenti ed eliminazioni devono essere disposti con un nome di colonna, un nome di tabella e uno in cui clausola / ordine per clausola per riga in modo che possano essere facilmente commentati uno alla volta durante il debug.

• Prefisso per i tipi di oggetto, in particolare dove potrebbero essere confusi (quindi v per view è il più importante). Non sono sicuro se si applica ancora, ma era inefficiente per le procedure memorizzate diverse dalle procedure di sistema per iniziare sp_. Probabilmente la migliore pratica per differenziarli comunque usp_ è stata quella che ho usato più di recente.

• Uno standard che indica come il nome di un trigger dovrebbe includere se è per aggiornamento / inserimento / eliminazione e la tabella a cui si applica. Non ho uno standard preferito ma si tratta di informazioni critiche e deve essere facile da trovare.

• Standard per la proprietà degli oggetti nelle versioni precedenti di SQL Server o dello schema in cui dovrebbe esistere per il 2005 e successivi. È la tua chiamata quello che è ma non dovresti mai indovinare chi possiede qualcosa / dove vive) e dove possibile lo schema / proprietario dovrebbe essere incluso negli script CREATE per ridurre al minimo la possibilità che venga creato in modo errato.

• Un indicatore del fatto che chiunque utilizzi SELECT * verrà costretto a bere una pinta di urina.

• A meno che non ci sia una ragione molto, molto buona (che non include la pigrizia da parte tua), avere, far rispettare e mantenere le relazioni chiave primaria / chiave esterna fin dall'inizio. Dopotutto, questo è un database relazionale, non un file flat e i record orfani renderanno il tuo supporto un inferno a un certo punto. Inoltre, tieni presente che se non lo fai ora posso prometterti che non riuscirai mai a implementarlo dopo l'evento perché sono 10 volte il lavoro una volta che hai i dati (che sarà un po 'fregato perché non hai mai applicato le relazioni correttamente).

Sono sicuro di aver perso qualcosa, ma per me sono quelli che offrono davvero un vero vantaggio in un numero decente di situazioni.

Ma come per tutti gli standard, meno è di più. Più sono lunghi gli standard di codifica, meno è probabile che le persone li leggano e li utilizzino. Una volta superate un paio di pagine ben distanziate, inizia a cercare di eliminare le cose che non fanno davvero la differenza nel mondo reale perché stai solo riducendo la possibilità che le persone lo facciano.

EDIT: due correzioni - inclusi gli schemi nella sezione di proprietà, rimuovendo un suggerimento errato sul conteggio (*) - vedi i commenti qui sotto.

non sembrano esserci risorse là fuori sul consenso per ciò che determina SQL ben scritto

Questo perché non c'è consenso. Ad esempio, avrei risposte diverse per almeno la metà degli articoli nella lista di Jon Hopkins e, in base alla quantità di dettagli nella sua lista, è una supposizione 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 concordano è una cosa migliore, perché è più probabile che tale standard venga seguito.

Oltre alla risposta di Jon Hopkins ...

• Separare gli oggetti interni da quelli esterni

  • IX, UQ, TRG, CK ecc. Per vincoli e indici ecc
  • minuscole o CapsCase per il client rivolto ad esempio uspThing_Add

• Per gli oggetti interni, rendili espliciti se "non predefinito"

  • UQ = vincolo univoco
  • UQC = vincolo cluster univoco
  • PK = chiave primaria
  • PKN = chiave primaria non cluster
  • IX = indice
  • IXU = indice univoco
  • IXC = indice cluster
  • IXCU o IXUC = indice cluster univoco

• Usa gli schemi per semplificare la denominazione + le autorizzazioni. Esempi:

  • Helper.xxx per processi interni
  • HelperFn.xxx per udfs
  • WebGUI.xxx per alcuni codici di fronte
  • Dati e / o cronologia e / o gestione temporanea per le tabelle