Nel mondo dei database, ci sono alcune cose che sono universalmente concordate. L'aumento della RAM è ampiamente vantaggioso per i sistemi DMBS. La diffusione di dati e file di registro su RAID migliora le prestazioni.
Le convenzioni di denominazione non sono una di quelle cose.
Questo è un argomento sorprendentemente polarizzante, con i fautori di varie metodologie saldamente radicati nelle loro posizioni. E molto vocale e appassionato nella loro difesa dello stesso.
Questo articolo approfondirà alcune convenzioni specifiche e gli argomenti di entrambe le parti, tentando di presentare una conclusione ragionevole per ogni punto.
Il grande dibattito sulla pluralizzazione
In fondo, questo è un argomento semplice. Ad esempio, qual è il modo corretto per denominare una tabella che contiene informazioni sui clienti in uno schema di database relazionale? È Customer o Customers ?
Gli argomenti da entrambe le parti abbondano.
A prima vista , viene naturale pensare a una collezione di oggetti al plurale. Un gruppo di più individui o società sarebbe Clienti . Pertanto, una tabella (essendo una raccolta di oggetti) dovrebbe essere nominata al plurale. Una singola riga in quella tabella sarebbe un singolo cliente .
I principi di denominazione ISO/IEC, sebbene datati, raccomandano nomi di tabelle pluralizzati e nomi di colonne singolari.
La maggior parte delle tabelle di sistema di SQL Server utilizza nomi plurali (sysnotifications , operatori di sistema ), ma questo non è coerente. Perché sysproxylogin e non sysproxylogins ?
Negli argomenti per nomi di tabelle plurali, le righe di una tabella sono anche indicate come "istanze" di un intero, in modo simile agli elementi di una raccolta. Clienti definisce l'intero set; un unico cliente è un'istanza di Clienti .
Al contrario, ci sono molte ragioni per usare nomi di oggetti singolari.
Anche se potrebbero esserci molti articoli (o clienti ) in una tabella, la tabella stessa può essere considerata una singola entità. box of clients non è “un box of customer”, anche se contiene un gran numero di clienti all'interno. Inoltre, potrebbe esserci un solo elemento, o nessuno, all'interno del tavolo, rendendo "clienti" un termine improprio.
Se scegli di modificare il nome della tabella in base alle varianti di parole, possono emergere rapidamente delle incongruenze. Mentre molte parole saranno semplici (Cliente diventa Clienti , Prodotto diventa Prodotti ), altre parole potrebbero non esserlo. In questo caso, Persona potrebbero diventare Persone o Persone; un singolare Alce avrebbe lo stesso aspetto della sua forma plurale, Moose . (Anche se perché avresti bisogno di una tavola di alci?) Una convenzione come People.FirstName inizia a diventare poco chiaro.
Se sono coinvolte più lingue, la situazione peggiora. Poiché la pluralizzazione delle parole può variare in tanti modi (clienti, topi, alci, bambini, crisi, programmi, aerei), i non madrelingua hanno ulteriori sfide. Attenersi a nomi di oggetti singolari evita completamente questo problema.
La questione della convenzione sul caso
Non c'è lo stesso fervore con le convenzioni sui casi come con la pluralizzazione, ma vengono avanzate argomentazioni per diverse opzioni. Includono:
- Caso Pascal :La prima lettera di ogni parola concatenata è in maiuscolo, come in:
CustomerOrder -
Custodia cammello :La prima lettera della prima parola è minuscola; tutte le successive parole concatenate hanno la prima lettera maiuscola, come in:
customerOrderPascal Case è talvolta considerato un sottotipo di Camel Case, ma Microsoft generalmente distingue tra i due.
Per le parole con meno di tre caratteri, si consiglia di utilizzare solo lettere maiuscole, come in
UIoIO. - Sottolinea [caso "C"] :le parole sono separate da trattini bassi, come in
Customer_Orderocustomer_Order– ancora più decisioni!
I ricercatori della Johns Hopkins University hanno condotto uno studio sull'efficienza dell'utilizzo dei caratteri di sottolineatura nella programmazione dei nomi degli oggetti. Hanno scoperto che l'uso di Camel Case (o Pascal Case) migliorava la precisione e il riconoscimento della digitazione. I trattini bassi sono stati ampiamente utilizzati nella programmazione C, ma la tendenza è verso Camel/Pascal Case con una recente enfasi sui linguaggi in stile Microsoft e Java.
Come per gli altri argomenti, seguente una convenzione stabilita è più importante della selezione della convenzione stessa.
Un'ulteriore considerazione qui è la distinzione tra maiuscole e minuscole del database. Le regole di confronto di SQL Server determinano questa sensibilità con "CS" (senza distinzione tra maiuscole e minuscole) o "CI" (senza distinzione tra maiuscole e minuscole) nel nome delle regole di confronto. Ad esempio:
SQL_Latin1_General_Cp437_CS_AS_KI_WI: Case Sensitive SQL_Latin1_General_Cp437_CI_AS_KI_WI: Case Insensitive
Nelle regole di confronto con distinzione tra maiuscole e minuscole, Select * from myTable fallirebbe contro l'oggetto MyTable . Ciò potrebbe rendere leggermente preferibile il carattere di sottolineatura per evitare confusione, ma Intellisense aiuta anche a eliminare gli errori di battitura nella maggior parte degli ambienti di programmazione moderni.
Altre considerazioni sulla convenzione di denominazione
Il dibattito tra singolare e plurale e la questione del grande caso potrebbe essere il luogo in cui la battaglia è più feroce, ma ci sono almeno altre tre aree da tenere a mente quando si considera una convenzione di denominazione.
Evita di utilizzare parole riservate di SQL Server come nomi di oggetti. Ciò include sia le tabelle che le colonne. Ad esempio:Utente , Ora e Data sono riservati. Le parole chiave riservate possono richiedere ulteriore attenzione per fare riferimento (come l'utilizzo di parentesi quadre) a seconda dell'applicazione chiamante. Questo vale anche per gli spazi. Gli spazi nei nomi degli oggetti richiedono virgolette per fare riferimento.
Questo si collega anche con un'altra raccomandazione:la precisione. System.CreateDate è molto più chiaro di System.Date . Un modello ben progettato consente allo spettatore di comprendere immediatamente lo scopo degli oggetti sottostanti. Quando qualsiasi identificatore deve essere referenziato come chiavi esterne, sii liberale nel nome:Customer.CustomerID anziché ID.cliente .
Evita prefissi e suffissi per tabelle e viste , come tblTable . La notazione ungherese (che è sempre stata intesa per identificare l'utilizzo delle variabili) è scivolata nelle convenzioni di denominazione comuni di SQL Server, ma è ampiamente derisa. Gli identificatori di oggetto dovrebbero descrivere ciò che è contenuto all'interno, non l'oggetto stesso.
Tuttavia, i prefissi sono utili negli oggetti di supporto di SQL Server , poiché descrivono la natura funzionale dell'oggetto.
I seguenti sono prefissi comunemente accettati per gli oggetti di SQL Server:
- IX:Indice
- PK:chiave primaria
- FK:chiave esterna
- CK:verifica vincolo
- DF:predefinito
- UQ viene talvolta utilizzato anche per indici univoci.
Questo modello illustra i punti sopra definiti. Non richiede alcuna spiegazione in merito alla natura dei dati; vengono utilizzate convenzioni di denominazione singolari e sono presenti identificatori chiari.
Alla fine, ci sono vantaggi e svantaggi per ogni lato del dibattito sulla denominazione della convenzione. C'è un punto chiave, tuttavia, su cui entrambe le parti possono concordare:indipendentemente dalle decisioni prese, essere coerenti con la convenzione selezionata.
Quali convenzioni di denominazione SQL utilizzi e perché?
