Convenzioni di denominazione di database, tabelle e colonne? [chiuso]


791

Ogni volta che progetto un database, mi chiedo sempre se esiste un modo migliore di nominare un elemento nel mio database. Molto spesso mi pongo le seguenti domande:

  1. I nomi delle tabelle dovrebbero essere plurali?
  2. I nomi delle colonne dovrebbero essere singolari?
  3. Devo anteporre tabelle o colonne?
  4. Dovrei usare un caso per nominare gli articoli?

Esistono linee guida consigliate per la denominazione degli elementi in un database?


7
Penso che dovremmo nominare plurale per le tabelle e singolare per le colonne.
AZ_

7
Vedo una tabella come "memoria" con più elementi, non una singola "entità", quindi la chiamo plurale. Quando ho mappato le tabelle in oggetti, vorrei nominare gli oggetti singolari. Questa è solo la mia opinione personale.
dpp

2
@ Tryinko L'utilizzo dell'ID in tutto il luogo è SALUTO per chiunque faccia join di più tavoli. Non c'è modo possibile che il leggero vantaggio di sapere che questo è PK superi l'incredibile fastidio di ri-aliasing la colonna ID dang in ogni query sanguinaria più e più volte. Se vuoi un modo per indicare PK in una tabella, rendilo la prima colonna. Inoltre, denotare gli FK nei nomi delle colonne è nella mia mente un altro anti-pattern solidamente malvagio.
ErikE,

2
Dai un'occhiata a questa risposta .
PerformanceDBA

Risposte:


315

Consiglio di consultare i database di esempio di SQL Server di Microsoft: https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

L'esempio AdventureWorks utilizza una convenzione di denominazione molto chiara e coerente che utilizza nomi di schema per l'organizzazione di oggetti di database.

  1. Nomi singolari per le tabelle
  2. Nomi singolari per colonne
  3. Nome schema per prefisso tabelle (ad es. SchemeName.TableName)
  4. Involucro Pascal (aka custodia in cammello superiore)

14
wilsonmar.com/sql_adventureworks.htm è un'eccellente analisi dello schema AdventureWorks.
Daniel Trebbien,

209
Non mi affiderei a Microsoft per nessuno standard: se guardi il loro database northwind vedrai che usano tabelle plurali, nomi di colonne singolari, prefissi di schema per tabelle, prefissi di tabella per colonne di chiavi primarie, prefissi di vincoli di stile ungherese e peggio di tutti gli SPAZI "" per nomi di tabelle con più parole. Inoltre, le tabelle di sistema per SQL Server utilizzano plurali, quindi sembra che AdventureWorks fosse la pecora nera in questo gruppo.
Marco Papa,

63
Penso che il problema principale qui sia che la folla del nome del tavolo Singolare sembra considerare il tavolo come l'entità, piuttosto che la riga nel tavolo che fa la folla Plural. Devi chiederti quale sia. Se la tabella è solo un contenitore di righe, non è più logico utilizzare la denominazione plurale? Non nomineresti mai una raccolta in codice singolare, quindi perché dovresti nominare la tabella singolare? Perché l'incoerenza? Sento tutti gli argomenti su come si ordinano e usano nei join, ma quelli sembrano tutti argomenti molto fragili. Se tutto si riduce alle preferenze, andrò con coerenza e pluralizzazione.
Jason,

4
Considera anche quale direzione sta andando la marea. Sembra che stia andando nella direzione di nomi di tabelle plurali, soprattutto perché tutte le tabelle di sistema in SQL Server sono tutte plurali e il valore predefinito per Entity Framework è pronto all'uso. Se questa è la posizione di Microsoft, voglio andare nella direzione in cui saremo tra 20 anni. Anche le convenzioni del database Oracle dicono nomi di tabelle plurali. Basti pensare a quanti sviluppatori c # odiavano la parola chiave "var" quando è stata introdotta, ora è il modo ampiamente accettato di definire le variabili.
Jason,

7
@Jasmine - Vedo il tuo punto di vista, anche se penso che tu abbia inavvertitamente chiamato la tua tabella di esempio al contrario. "TableOfInvoices" deve essere abbreviato in "Invoices", che è ciò che preferisco. Probabilmente invece intendevi "InvoiceTable", che ha senso abbreviare "Invoice".
Derek,

280

Risposta in ritardo qui, ma in breve:

  1. La mia preferenza è al plurale
  2. Tabelle : * Di solito * nessun prefisso è il migliore. Colonne : No.
  3. Sia tabelle che colonne: PascalCase.

Elaborazione:

(1) Cosa devi fare. Ci sono pochissime cose che devi fare in un certo modo, ogni volta, ma ce ne sono alcune.

  • Assegna un nome alle chiavi primarie utilizzando il formato "ID [singularOfTableName]". Ovvero, sia che il nome della tabella sia Cliente o Clienti , la chiave primaria dovrebbe essere CustomerID .
  • Inoltre, le chiavi esterne devono essere denominate in modo coerente in tabelle diverse. Dovrebbe essere legale picchiare qualcuno che non lo fa. Sottolineerei che mentre i vincoli di chiave esterna definiti sono spesso importanti, la denominazione coerente delle chiavi esterne è sempre importante
  • Il database deve avere convenzioni interne . Anche se nelle sezioni successive mi vedrai molto flessibile, all'interno di un database la denominazione deve essere molto coerente. Indipendentemente dal fatto che la tabella per i clienti sia denominata Clienti o Cliente, è meno importante che lo si faccia nello stesso database. E puoi lanciare una moneta per determinare come usare i trattini bassi, ma poi devi continuare a usarli allo stesso modo . Se non lo fai, sei una persona cattiva che dovrebbe avere una bassa autostima.

(2) Cosa dovresti probabilmente fare.

  • I campi che rappresentano lo stesso tipo di dati su tabelle diverse devono essere denominati uguali. Non avere Zip su un tavolo e ZipCode su un altro.
  • Per separare le parole nei nomi delle tabelle o delle colonne, usa PascalCasing. L'uso di CamelCasing non sarebbe intrinsecamente problematico, ma questa non è la convenzione e sembrerebbe divertente. Tratterò i trattini bassi tra un momento. (Non puoi usare ALLCAPS come ai vecchi tempi. OBNOXIOUSTABLE.ANNOYING_COLUMN andava bene in DB2 20 anni fa, ma non ora.)
  • Non abbreviare o abbreviare artificialmente le parole. È meglio che un nome sia lungo e chiaro che breve e confuso. I nomi ultra-corti rappresentano un passaggio dai tempi più scuri e più selvaggi. Cus_AddRef. Cosa diavolo è quello? Riferimento del destinatario custodiale? Rimborso aggiuntivo del cliente? Referral indirizzo personalizzato?

(3) Cosa dovresti considerare.

  • Penso davvero che dovresti avere nomi plurali per le tabelle; alcuni pensano singolare. Leggi gli argomenti altrove. I nomi delle colonne dovrebbero essere singolari comunque. Anche se usi nomi di tabelle plurali, le tabelle che rappresentano combinazioni di altre tabelle potrebbero essere al singolare. Ad esempio, se si dispone di una tabella Promozioni e Articoli , una tabella che rappresenta un articolo che fa parte di una promozione potrebbe essere Promozioni_Articoli, ma potrebbe anche legittimamente essere Promozione_Articoli penso (che riflette la relazione uno-a-molti).
  • Usa i trattini bassi in modo coerente e per uno scopo particolare. Solo i nomi delle tabelle generali dovrebbero essere abbastanza chiari con PascalCasing; non hai bisogno di trattini bassi per separare le parole. Salva i caratteri di sottolineatura (a) per indicare una tabella associativa o (b) per il prefisso, che affronterò nel prossimo punto.
  • Il prefisso non è né buono né cattivo. Di solito non è il massimo. Nel tuo primo o secondo db, non suggerirei di utilizzare i prefissi per il raggruppamento tematico generale di tabelle. Le tabelle finiscono per non adattarsi facilmente alle tue categorie e può effettivamente rendere più difficile trovare le tabelle. Con l'esperienza, puoi pianificare e applicare uno schema di prefisso che fa più bene che male. Una volta ho lavorato in un db dove le tabelle di dati sono iniziate con tbl , le tabelle di configurazione con ctbl , le visualizzazioni con vew , proc's sp e udf's fne pochi altri; è stato meticolosamente, applicato in modo coerente, quindi ha funzionato bene. L'unica volta in cui hai BISOGNO dei prefissi è quando hai soluzioni veramente separate che per qualche ragione risiedono nello stesso db; il prefisso può essere molto utile nel raggruppare le tabelle. Il prefisso va bene anche per situazioni speciali, come per le tabelle temporanee che si desidera distinguere.
  • Molto raramente (se mai) vorresti aggiungere un prefisso alle colonne.

11
"I campi che rappresentano lo stesso tipo di dati su tabelle diverse devono essere denominati uguali. Non avere Zip su una tabella e ZipCode su un'altra." Sì sì un milione di volte sì. Puoi dire che il nostro database non è stato progettato in questo modo? A una persona potrebbe essere fatto riferimento in una dozzina di modi diversi, molto fastidiosi da mantenere. Ho sempre rispettato questa regola in qualsiasi database avessi il controllo sulla progettazione e rende la vita molto più semplice.
HLGEM,

87
Penso che la chiave primaria dovrebbe essere solo "ID". Una convenzione così semplice rende la chiave primaria prevedibile e rapidamente identificabile. Vorrei tuttavia anteporre il nome della tabella ("PersonID") quando viene utilizzato come chiave esterna in altre tabelle. Questa convenzione potrebbe aiutare a distinguere tra una chiave primaria e chiavi esterne nella stessa tabella.
Triynko,

55
@ Tryinko L'utilizzo dell'ID in tutto il luogo è SALUTO per chiunque faccia join di più tavoli. Non c'è modo possibile che il leggero vantaggio di sapere che questo è PK superi l'incredibile fastidio di ri-aliasing la colonna ID dang in ogni query sanguinaria più e più volte. Se vuoi un modo per indicare PK in una tabella, rendilo la prima colonna. Inoltre, denotare gli FK nei nomi delle colonne è nella mia mente un altro anti-pattern solidamente malvagio.
ErikE,

18
@Triynko se usi solo "ID", diventa anche programmaticamente impossibile determinare la tabella a cui appartiene. Con il prefisso del nome della tabella, puoi semplicemente tagliare le ultime due cifre di una chiave primaria e conoscere il nome della tabella a cui appartiene tramite il codice. Molte volte le persone IT e DBA non si rendono conto che ci sono vantaggi di programmazione per i programmatori nella progettazione di database in determinati modi.
dallin

16
@ErikE Voglio dire, non sai se CustomerIDè la chiave primaria della Customertabella o una chiave esterna in un'altra tabella. È un problema minore. Perché vorresti usare nomi poveri come c? CustomerID = Customer.IDè molto chiaro in quanto vedi che stai unendo una chiave esterna con una chiave primaria; non è ridondante in quanto le due parti sono due cose diverse. La denominazione di un singolo personaggio è una cattiva pratica dell'IMO.
Dave Cousineau,

100

Ok, dato che valutiamo l'opinione:

Credo che i nomi delle tabelle dovrebbero essere al plurale. Le tabelle sono una raccolta (una tabella) di entità. Ogni riga rappresenta una singola entità e la tabella rappresenta la raccolta. Quindi chiamerei una tabella di entità Person Persone (o Persone, qualunque cosa tu voglia).

Per coloro a cui piace visualizzare singolari "nomi di entità" nelle query, è quello che utilizzerei gli alias di tabella per:

SELECT person.Name
FROM People person

Un po 'come LINQ "from person in people select person.Name".

Per quanto riguarda 2, 3 e 4, sono d'accordo con @Lars.


17
@Emtucifor: in inglese, non diciamo "Guarda tutta la persona là fuori in quella folla di persone!" Avere un problema concettuale con cose a cui si fa riferimento multiplo con una sola parola è prevedibile. Non è né normale né corretto. "Dati" è eccezionale e spesso usato per riferirsi a un pezzo di un volume di sostanza, molto simile a "torta". "Vorresti una fetta di torta?" Denominare una tabella "Persone" perché contiene informazioni su più individui ha molto più senso che denominarla "Persona". Una classe di dati denominata "Person" per la riga ha senso, così come i nomi di singole colonne.
Triynko,

6
@Emtucifor: in definitiva tutta la lingua è arbitraria e convenzionale. Stavo solo sostenendo che convenzionalmente ci riferiamo a una raccolta di oggetti come il plurale del tipo di oggetto in esso. Quindi una raccolta di righe in cui ogni riga contiene informazioni su una singola persona verrebbe richiamata come una raccolta di persone. Ma se vuoi riferirti ad esso come una raccolta di Person, vai avanti.
Triynko,

3
@Emtucifor: Sì, lol. La denominazione della tabella "PersonCollection" equivarrebbe a denominarla "Persone". Contrasto che con la denominazione di una tale raccolta solo "Person", che non ha senso :)
Triynko

4
@Emtucifor: allora pensiamolo da un'altra prospettiva per mettere la convenzione di denominazione in un contesto. Supponiamo di avere classi di oggetti per rappresentare sia la riga che la tabella. "Person" ha ovviamente senso per la classe che rappresenta una riga di dati. Se il tuo tavolo è stato anche chiamato "Persona", potresti avere un conflitto di nomi o un po 'di confusione. Penso solo che abbia più senso nominare gli oggetti con una pluralità accurata. Una riga con i dati su una persona dovrebbe essere chiamata Persona e una tabella con informazioni su persone o più persone si chiama Persone, PersonCollection, Persone, ecc.
Triynko

5
@Josh M. Beh, non in entrambi i casi. Se segui la mia strada, puoi alias la tabella People come "person" e avere SELECT person.Name. Problema risolto. ;-)
Matt Hamilton,

73

Lavoro in un team di supporto per database con tre DBA e le nostre opzioni considerate sono:

  1. Qualsiasi standard di denominazione è migliore di nessuno standard.
  2. Non esiste un "unico vero" standard, tutti abbiamo le nostre preferenze
  3. Se è già presente uno standard, utilizzalo. Non creare un altro standard o confondere gli standard esistenti.

Usiamo nomi singolari per le tabelle. Le tabelle tendono ad avere il prefisso con il nome del sistema (o il suo acronimo). Ciò è utile se il sistema è complesso in quanto è possibile modificare il prefisso per raggruppare le tabelle in modo logico (ad es. Reg_customer, reg_booking e regadmin_limits).

Per i campi prevediamo che i nomi dei campi includano il prefisso / acryonm della tabella (es. Indirizzo_cust1) e preferiamo anche l'uso di un set standard di suffissi (_id per il PK, _cd per "code", _nm per "name" ", _nb per" numero ", _dt per" Data ").

Il nome del campo Chiave Foriegn deve essere uguale al campo Chiave primaria.

vale a dire

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

Durante lo sviluppo di un nuovo progetto, ti consiglio di scrivere tutti i nomi di entità, prefissi e acronimi preferiti e di consegnare questo documento ai tuoi sviluppatori. Quindi, quando decidono di creare una nuova tabella, possono fare riferimento al documento anziché "indovinare" come dovrebbero essere chiamati la tabella e i campi.


9
Soprattutto per il numero 3, avevamo un gruppo di persone che erano state assunte dalla stessa azienda e hanno cercato di imporre il loro vecchio standard di denominazione (che nessuno degli altri usava) su qualsiasi cosa facessero. Molto noioso.
HLGEM,

40
Certamente rende illeggibile SQL; ma penso di poter tradurre. cust_nm dovrebbe essere CustomerName , booking_dt dovrebbe essere BookingDate . reg_customer, beh non ho idea di cosa sia.
Ian Boyd,

3
@Ian. L'intenzione è quella di attenersi alla convinzione di denominazione a cui sei abituato e mantenerla coerente. So SEMPRE che qualsiasi campo data è _dt, qualsiasi campo nome è _nm. 'reg' è un esempio di un sistema di "registrazione" (prenotazioni, clienti ecc.) e tutte le relative tabelle avrebbero lo stesso prefisso. Ma ognuno per conto suo ...
Guy,

7
concordo sul fatto che uno standard particolare non è importante quanto uno standard coerente. Ma alcuni standard sono sbagliati. DB2 e nomi di colonne come CSPTCN, CSPTLN, CSPTMN, CSDLN. Le persone dovrebbero imparare che sono stati inventati nomi lunghi: possiamo permetterci di rendere le cose leggibili.
Ian Boyd,

17
Nel corso degli anni, ho aggiunto nuove colonne alla fine dei miei tavoli nell'app che ho sviluppato e commercializzato. A volte, utilizzo i nomi inglesi nelle mie colonne, a volte uso lo spagnolo e talvolta riutilizzo le colonne per qualcos'altro, invece di eliminarle e aggiungere una nuova colonna con un nome descrittivo appropriato per ciò che viene utilizzato. L'ho fatto di proposito per OBFUSCARE il mio codice sorgente nel caso in cui qualcun altro cerchi di hackerare o decodificare il mio codice. Solo io posso capirlo, qualcun altro si sentirà frustrato! .. In questo modo, devono sempre fare affidamento su di me per qualsiasi cosa!
Frank R.

47
  1. No. Una tabella dovrebbe essere chiamata come l'entità che rappresenta. Persona, non persone è come faresti riferimento a chiunque rappresenti uno dei registri.
  2. Ancora una volta, stessa cosa. La colonna FirstName in realtà non dovrebbe essere chiamata FirstNames. Tutto dipende da cosa vuoi rappresentare con la colonna.
  3. NO.
  4. Sì. Caso per chiarezza. Se devi avere colonne come "FirstName", il case renderà più facile la lettura.

Ok. Questo è il mio $ 0,02


5
Aggiungendo un po 'di chiarezza al numero 3 - i prefissi sono un modo per incorporare metadati nel nome della colonna. Non dovrebbe essere necessario farlo in qualsiasi DB moderno per gli stessi motivi della (notazione eccessiva) della notazione ungherese.
Mark McDonald

21
`seleziona i primi 15 dagli ordini 'o' seleziona i primi 15 dagli ordini '? Quest'ultima è la mia preferenza (umana).
Ian Boyd,

8
@Ian Boyd: Sì: SELEZIONA I TOP 100 * DA Rapporto R INNER JOIN VisitReport VR ON R.ReportID = VR.ReportID. Tutto dipende da come ci pensi. Se metti una foto di un limone su un contenitore, sapresti che c'erano dei limoni all'interno, senza bisogno di due limoni all'esterno per indicare che potrebbe essere al plurale. Certo, potresti etichettarlo con la parola scritta "limoni". Ma potrebbe anche essere "limone". Per acquisire la risorsa denominata "limone", vai qui.
ErikE,

6
aggiungi $ 0,01 per l'utilizzo di UpperCase nei nomi delle colonne e aggiungi altri $ 0,01 per l'utilizzo del trattino basso nei nomi delle colonne in modo che sia più facile distinguere i nomi delle colonne in bella vista. Totale = La mia donazione di $ 0,02 a te!
Frank R.

6
"Una tabella dovrebbe essere chiamata come l'entità che rappresenta" Una tabella è una raccolta di entità. Mentre una tabella è anche un'entità, è un'entità di tipo "Tabella" che è inutile aggiungere al suo nome.
Trisped

34

Sono anche a favore di una convenzione di denominazione in stile ISO / IEC 11179, osservando che sono linee guida piuttosto che prescrittive.

Vedi Nome dell'elemento dati su Wikipedia :

"Le tabelle sono raccolte di entità e seguono le linee guida per la denominazione delle raccolte. Idealmente, viene utilizzato un nome collettivo: ad es., Personale. Plurale è anche corretto: Impiegati. I nomi errati includono: Impiegato, tblEmployee e EmployeeTable."

Come sempre, ci sono eccezioni alle regole, ad esempio una tabella che ha sempre esattamente una riga può essere migliore con un nome singolare, ad esempio una tabella di configurazione. E la coerenza è della massima importanza: controlla se il tuo negozio ha una convenzione e, in tal caso, seguila; se non ti piace, fai un caso aziendale per cambiarlo piuttosto che essere il ranger solitario.


-1: il testo di riferimento non ha nulla a che fare con ISO / IEC 11179. La pagina di Wikipedia di riferimento non dovrebbe essere attendibile; leggi invece lo standard attuale ( metadata-standards.org/11179/#A5 )
mkadunc,

@onedaywhen: non so abbastanza sull'argomento per correggere la pagina di Wikipedia; Inoltre, la pagina di Wikipedia non è tanto sbagliata quanto fuorviante: non dice esplicitamente che ISO / IEC 11179 include le convenzioni di denominazione del database, dice solo che "ISO / IEC 11179 è applicabile quando si nominano tabelle e colonne all'interno di un database relazionale ". Successivamente, fornisce un esempio di convenzioni di denominazione che potrebbero essere utilizzate per il database relazionale. Ti permette di pensare che l'esempio sia qualcosa preso dallo standard, quando è davvero qualcosa inventato dallo scrittore dell'articolo di Wikipedia.
mkadunc,

27

Sento sempre l'argomentazione secondo cui se un tavolo è o meno pluralizzato è tutta una questione di gusti personali e non esiste una buona pratica. Non credo sia vero, soprattutto come programmatore rispetto a un DBA. Per quanto ne so, non ci sono ragioni legittime per pluralizzare un nome di tabella diverso da "Ha senso solo perché è una raccolta di oggetti", mentre ci sono guadagni legittimi nel codice con nomi di tabella singolari. Per esempio:

  1. Evita bug ed errori causati da ambiguità plurali. I programmatori non sono esattamente conosciuti per la loro competenza ortografica e il pluralismo di alcune parole è confuso. Ad esempio, la parola plurale termina con 'es' o semplicemente 's'? Sono persone o persone? Quando lavori su un progetto con team di grandi dimensioni, questo può diventare un problema. Ad esempio, un'istanza in cui un membro del team utilizza il metodo errato per pluralizzare una tabella che crea. Quando interagisco con questa tabella, viene utilizzata dappertutto nel codice a cui non ho accesso o che richiederebbe troppo tempo per la correzione. Il risultato è che devo ricordare di aver sbagliato a scrivere la tabella ogni volta che la uso. Mi è successo qualcosa di molto simile a questo. Più è facile per ogni membro del team utilizzare in modo coerente e semplice l'esatto, correggere i nomi delle tabelle senza errori o cercare sempre i nomi delle tabelle, meglio è. La versione singolare è molto più semplice da gestire in un ambiente di squadra.

  2. Se si utilizza la versione singolare del nome di una tabella E il prefisso della chiave primaria con il nome della tabella, ora si ha il vantaggio di determinare facilmente un nome di tabella da una chiave primaria o viceversa solo tramite il codice. Puoi ricevere una variabile con un nome di tabella, concatenare "Id" fino alla fine e ora hai la chiave primaria della tabella tramite codice, senza dover eseguire una query aggiuntiva. Oppure puoi tagliare "Id" dalla fine di una chiave primaria per determinare il nome di una tabella tramite codice. Se si utilizza "id" senza un nome di tabella per la chiave primaria, non è possibile tramite il codice determinare il nome della tabella dalla chiave primaria. Inoltre, la maggior parte delle persone che pluralizzano nomi di tabelle e prefissi colonne PK con il nome della tabella utilizzano la versione singolare del nome della tabella nel PK (ad esempio status e status_id),

  3. Se rendi singolari i nomi delle tabelle, puoi farli corrispondere ai nomi delle classi che rappresentano. Ancora una volta, questo può semplificare il codice e consentirti di fare cose davvero ordinate, come creare un'istanza di una classe non avendo nient'altro che il nome della tabella. Inoltre, rende il codice più coerente, il che porta a ...

  4. Se rendi singolare il nome della tabella, il tuo schema di denominazione sarà coerente, organizzato e facile da mantenere in ogni posizione. Sai che in ogni istanza nel tuo codice, sia che si tratti di un nome di colonna, come un nome di classe o come il nome della tabella, è lo stesso nome esatto. Ciò consente di eseguire ricerche globali per vedere ovunque vengano utilizzati i dati. Quando si plurale un nome di tabella, ci saranno casi in cui si utilizzerà la versione singolare di quel nome di tabella (la classe in cui si trasforma, nella chiave primaria). Ha senso non avere alcuni casi in cui i tuoi dati vengono definiti plurali e alcuni casi singolari.

Per riassumere, se si pluralizzano i nomi delle tabelle si stanno perdendo tutti i tipi di vantaggi nel rendere il codice più intelligente e più facile da gestire. Ci possono anche essere casi in cui devi avere tabelle / array di ricerca per convertire i nomi delle tue tabelle in oggetti o nomi di codici locali che potresti aver evitato. I nomi di tabelle singolari, sebbene all'inizio possano sembrare un po 'strani, offrono vantaggi significativi rispetto ai nomi pluralizzati e credo che siano le migliori pratiche.


26

la nostra preferenza:

  1. I nomi delle tabelle dovrebbero essere plurali?
    Mai. Gli argomenti per cui si tratta di una raccolta hanno un senso, ma non si sa mai cosa conterrà la tabella (0,1 o molti articoli). Le regole plurali rendono inutilmente complicata la denominazione. 1 casa, 2 case, mouse contro topi, persona contro persone, e non abbiamo nemmeno guardato altre lingue.

    Update person set property = 'value'agisce su ogni persona nella tabella.
    Select * from person where person.name = 'Greg'restituisce una raccolta / set di righe di righe di persone.

  2. I nomi delle colonne dovrebbero essere singolari?
    Di solito sì, tranne dove stai infrangendo le regole di normalizzazione.

  3. Devo anteporre tabelle o colonne?
    Principalmente una preferenza di piattaforma. Preferiamo aggiungere il prefisso alle colonne con il nome della tabella. Non facciamo prefisso tabelle, ma facciamo prefisso viste (v_) e stored_procedures (sp_ o f_ (funzione)). Ciò aiuta le persone che vogliono provare a aggiornare v_person.age che in realtà è un campo calcolato in una vista (che non può essere comunque AGGIORNATO).

    È anche un ottimo modo per evitare la collisione delle parole chiave (delivery.from si rompe, ma delivery_from no).

    Rende il codice più dettagliato, ma spesso aiuta nella leggibilità.

    bob = new person()
    bob.person_name = 'Bob'
    bob.person_dob = '1958-12-21'
    ... è molto leggibile ed esplicito. Questo può sfuggire di mano però:

    customer.customer_customer_type_id

    indica una relazione tra cliente e la tabella customer_type, indica la chiave primaria nella tabella customer_type (customer_type_id) e se si vede mai 'customer_customer_type_id' durante il debug di una query, si sa immediatamente da dove proviene (tabella del cliente).

    o dove hai una relazione MM tra customer_type e customer_category (solo alcuni tipi sono disponibili per determinate categorie)

    customer_category_customer_type_id

    ... è un po '(!) sul lato lungo.

  4. Dovrei usare un caso per nominare gli articoli? Sì - lettere minuscole :), con caratteri di sottolineatura. Questi sono molto leggibili e multipiattaforma. Insieme a 3 sopra ha anche senso.

    La maggior parte di questi sono preferenze però. - Fintanto che sei coerente, dovrebbe essere prevedibile per chiunque debba leggerlo.


1
SELECT * FROM people AS person WHERE person.name = 'Greg'sembra il più naturale per me.
Kenmore,

1
@Zuko Principalmente, la convenzione di denominazione per la chiave primaria della tabella è <table name><id>, ad esempio PersonIDo Person_IDecc. Pertanto, ha più senso che NON si nominino le tabelle al plurale poiché ogni record è una persona separata non persone.
Mr. Blond,


15

So che questo è in ritardo al gioco, e alla domanda è già stata data una risposta molto buona, ma voglio offrire la mia opinione su # 3 per quanto riguarda il prefisso dei nomi delle colonne.

Tutte le colonne devono essere denominate con un prefisso univoco per la tabella in cui sono definite.

Ad esempio, date le tabelle "cliente" e "indirizzo", andiamo rispettivamente con i prefissi di "cust" e "addr". "cliente" avrebbe "cust_id", "cust_name", ecc. al suo interno. "address" avrebbe "addr_id", "addr_cust_id" (FK torna al cliente), "addr_street", ecc. in esso.

Quando mi è stato presentato per la prima volta questo standard, sono stato messo a dura prova contro di esso; Ho odiato l'idea. Non potevo sopportare l'idea di tutta quella digitazione e ridondanza in più. Ora ho avuto abbastanza esperienza con esso che non ci tornerò mai più.

Il risultato è che tutte le colonne nello schema del database sono uniche. C'è un grande vantaggio in questo, che vince su tutti gli argomenti (a mio avviso, ovviamente):

Puoi effettuare ricerche nell'intera base di codici e trovare in modo affidabile ogni riga di codice che tocca una determinata colonna.

Il vantaggio del n. 1 è incredibilmente enorme. Posso deprecare una colonna e sapere esattamente quali file devono essere aggiornati prima che la colonna possa essere rimossa in modo sicuro dallo schema. Posso cambiare il significato di una colonna e sapere esattamente quale codice deve essere refactored. Oppure posso semplicemente dire se i dati di una colonna vengono persino utilizzati in una particolare porzione del sistema. Non posso contare il numero di volte in cui questo ha trasformato un progetto potenzialmente enorme in un progetto semplice, né la quantità di ore che abbiamo risparmiato nel lavoro di sviluppo.

Un altro vantaggio relativamente minore è che devi usare solo alias di tabella quando esegui un self join:

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

1
Quindi non puoi più reliably find every line of code that touches a particular column... Non è questo il punto?
Raveren,

6
@Raveren - Puoi ancora. Se tutto ciò che fai è "SELEZIONA *", la query è irrilevante per questo scopo. Quando / Se in seguito, usi i risultati di quella query, devi usare il nome della colonna per fare qualcosa con i suoi dati, quindi questo è il punto di cui devi preoccuparti nel tuo codice, non nell'istruzione SQL.
Granger,

Sarò curioso di sapere quali situazioni richiedono SELECT *? Non vorrei certo che nessuno lo usasse nel codice di produzione. Sì, è utile per query ad hoc e per scoprire quale dato sta rendendo dispari i risultati delle query a join multipli, ma non riesco a pensare a nessun posto nel codice di produzione dove è richiesto.
HLGEM,

2
A meno che tu non stia codificando l'intera app in un linguaggio non OO, avere un livello ORM decente rende questo argomento ridondante.
Adam,

6
Quindi, a causa di questa risposta, ho deciso di provare a utilizzare i prefissi di tabella su un grande progetto e ho pensato di riportare indietro. Ha reso i tavoli di refactoring estremamente facili, il che è stato fantastico! Tuttavia, è stato un dolore più grande di quanto mi aspettassi. Il nostro database aveva molte tabelle denominate complesse. È facile ricordare che Cust è il prefisso per il Cliente, ma non è altrettanto facile ricordare il prefisso per HazardVerificationMethod. Ogni volta che scrivevo una tabella o un campo dovevo fare una pausa per pensare al prefisso. Alla fine ho deciso che la velocità e la convenienza erano più importanti della ricerca, ma ho pensato che fosse un'esperienza preziosa.
dallin

15

Le mie opinioni su questi sono:

1) No, i nomi delle tabelle dovrebbero essere singolari.

Mentre sembra avere senso per la selezione semplice ( select * from Orders) ha meno senso per l'equivalente OO ( Orders x = new Orders).

Una tabella in un DB è davvero l'insieme di quell'entità, ha più senso una volta che si utilizza set-logic:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

L'ultima riga, l'attuale logica del join, sembra confusa con nomi di tabelle plurali.

Non sono sicuro di usare sempre un alias (come suggerisce Matt) lo chiarisce.

2) Dovrebbero essere singolari poiché contengono solo 1 proprietà

3) Mai, se il nome della colonna è ambiguo (come sopra, dove entrambi hanno una colonna chiamata [Chiave]), il nome della tabella (o il suo alias) può distinguerli abbastanza bene. Desideri che le query siano veloci da digitare e semplici: i prefissi aggiungono complessità non necessaria.

4) Qualunque cosa tu voglia, suggerirei CapitalCase

Non credo che ci sia una serie di linee guida assolute su nessuna di queste.

Fintanto che qualunque cosa tu scelga sia coerente tra l'applicazione o il DB, non penso che sia davvero importante.


3
Che diamine è CapitalCase?
ViRuSTriNiTy

@ViRuSTriNiTy probabilmente intendevapascal case
marctrem,

Keith, al numero 3 faccio entrambe le cose, e sono incoerente (ma sto divagando), ma non capisco perché è male avere un nome di colonna descrittivo purché non sia esagerato, lo stesso con una tabella, un variabile, ecc.
johnny,

@johnny non è male, come tale, semplicemente non necessario. Perché digitare cose che non devi? Inoltre la maggior parte intellisense utilizza principalmente l'inizio del nome, quindi se avete Product.ProductName, Product.ProductID, Product.ProductPriceecc digitazione Product.Pti dà tutti i campi prefissati.
Keith,

13

Secondo me:

  1. I nomi delle tabelle dovrebbero essere al plurale.
  2. I nomi delle colonne dovrebbero essere singolari.
  3. No.
  4. CamelCase (il mio preferito) o underscore_separated sia per i nomi delle tabelle che per quelli delle colonne.

Tuttavia, come è stato menzionato, qualsiasi convenzione è meglio di nessuna convenzione. Non importa come scegli di farlo, documentalo in modo che le future modifiche seguano le stesse convenzioni.


1
per quanto riguarda # 4, PascalCase ... camelCase ... snake_case ...
Andrew

11

Penso che la migliore risposta a ciascuna di queste domande sarebbe stata data da te e dal tuo team. È molto più importante avere una convenzione di denominazione piuttosto che esattamente la convenzione di denominazione è.

Poiché non esiste una risposta corretta a ciò, dovresti prenderti un po 'di tempo (ma non troppo) e scegliere le tue convenzioni e - ecco la parte importante - attenersi ad essa.

Ovviamente è bene cercare alcune informazioni sugli standard in merito, che è quello che stai chiedendo, ma non preoccuparti o preoccuparti del numero di diverse risposte che potresti ottenere: scegli quella che ti sembra migliore.

Per ogni evenienza, ecco le mie risposte:

  1. Sì. Un tavolo è un gruppo di dischi , insegnanti o attori , quindi ... al plurale.
  2. Sì.
  3. Non li uso.
  4. Il database che utilizzo più spesso - Firebird - mantiene tutto in maiuscolo, quindi non importa. Ad ogni modo, quando sto programmando scrivo i nomi in modo che sia più facile da leggere, come releaseYear .

11
  1. Sicuramente mantenere i nomi delle tabelle singolari, persona non persone
    1. Anch'io
    2. No. Ho visto alcuni terribili prefissi, arrivando al punto di affermare che cosa stava trattando è una tabella (tbl_) o una procedura di archivio utente (usp_). Questo è seguito dal nome del database ... Non farlo!
    3. Sì. Tendo a PascalCase tutti i nomi delle mie tabelle

28
OH MIO DIO. NO. I nomi delle tabelle DEFINITAMENTE plurale. È una COLLEZIONE. Ha più cose in esso. "seleziona * da PERSONE". Non stai selezionando da una sola persona, stai selezionando da più PERSONE!
Triynko,

4
Mi è sempre piaciuto il modo in cui l'istruzione select suona meglio se è plurale. SELECT id,name FROM contacts WHERE email_address LIKE '%gmail%'tavoli plurali, colonne singolari. Ancora una volta sempre una questione di opinione personale.
scunliffe,

il prefisso tbl, qry ecc. può essere estremamente utile quando si gestiscono i metadati del database, se si sta esaminando l'oggetto in un database con una convenzione di denominazione semplice e veloce, è possibile accelerare notevolmente la comprensione
Cruachan,

9

Le convenzioni di denominazione consentono al team di sviluppo di progettare la rilevabilità e la manutenibilità al centro del progetto.

Una buona convenzione di denominazione richiede tempo per evolversi, ma una volta in atto consente al team di andare avanti con un linguaggio comune. Una buona convenzione di denominazione cresce organicamente con il progetto. Una buona convenzione di denominazione affronta facilmente le modifiche durante la fase più lunga e importante del ciclo di vita del software: gestione dei servizi in produzione.

Ecco le mie risposte:

  1. Sì, i nomi delle tabelle dovrebbero essere plurali quando si riferiscono ad una serie di operazioni , titoli o controparti per esempio.
  2. Sì.
  3. Sì. Le tabelle SQL hanno il prefisso tb_, le viste hanno il prefisso vw_, le procedure memorizzate hanno il prefisso usp_ e i trigger hanno il prefisso tg_ seguito dal nome del database.
  4. Il nome della colonna deve essere minuscolo separato da un trattino basso.

La denominazione è difficile ma in ogni organizzazione c'è qualcuno che può nominare le cose e in ogni team di software dovrebbe esserci qualcuno che si assume la responsabilità degli standard di denominazione e garantisce che i problemi di denominazione come sec_id , sec_value e security_id vengano risolti presto prima che vengano inseriti nel progetto .

Quindi quali sono i principi di base di una buona convenzione e standard di denominazione: -

  • Usa la lingua del tuo client e il dominio della tua soluzione
  • Sii descrittivo
  • Sii coerente
  • Disambiguare, riflettere e riflettere
  • Non usare abbreviazioni a meno che non siano chiare a tutti
  • Non utilizzare parole chiave riservate SQL come nomi di colonna

3
le tabelle sono per definizione relazioni. che sono in effetti singolari. i prefissi fanno schifo. Hai mai avuto bisogno di cambiare una tabella in una vista o viceversa? provalo con i prefissi. che differenza fa se è una vista o una tabella?
William Jones,

Il prefisso potrebbe essere utile laddove abbiamo lo stesso nome per due oggetti, come la funzione e la stored procedure. Avrei una funzione con nome "GetApproverList" e con lo stesso nome vorrei creare una procedura memorizzata che chiamerà questa funzione internamente. SQL non consentirà la creazione di due oggetti con lo stesso nome.
Ravinder Singh,


7
SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

2
Nota gli standard utilizzati: le tabelle contengono più elementi, gli utenti hanno un nome, parole chiave T-SQL in maiuscolo, definizioni di tabella nel caso Pascal.
Ian Boyd,

3
errore di battitura: Lastnamedovrebbe essereLastName
aminimalanimal

1
Il nome della tabella dovrebbe essere singolare, ovvero: Utente anziché Utente
AZ_

E nota come i nomi delle tabelle sono plurali; mentre trattengono gli utenti , non l' utente .
Ian Boyd il

5

I nomi delle tabelle dovrebbero essere sempre singolari, perché rappresentano un insieme di oggetti. Come dici tu branco di designare un gruppo di pecore, o gregge designare un gruppo di uccelli. Non è necessario il plurale. Quando un nome di tabella è composto da due nomi e la convenzione di denominazione è al plurale, diventa difficile sapere se il nome del plurale debba essere la prima parola o la seconda parola o entrambi. È la logica - Object.instance, non objects.instance. Oppure TableName.column, non TableNames.column (s). Microsoft SQL non fa distinzione tra maiuscole e minuscole, è più semplice leggere i nomi delle tabelle, se vengono utilizzate lettere maiuscole, per separare i nomi di tabelle o colonne quando sono composti da due o più nomi.


2
Una mandria è un gruppo di pecore . A nonUser è un gruppo di utenti.
EricRobertBrewer

4

Nome tabella: dovrebbe essere singolare, in quanto è un'entità singolare che rappresenta un oggetto del mondo reale e non oggetti, che è singolare.

Nome colonna: dovrebbe essere singolare solo dopo che trasmette che avrà un valore atomico e confermerà la teoria della normalizzazione. Se tuttavia, ci sono n numero dello stesso tipo di proprietà, allora dovrebbero essere suffissi 1, 2, ..., n, ecc.

Prefisso tabelle / colonne: è un argomento enorme, che verrà discusso più avanti.

Involucro: dovrebbe essere il caso del cammello

Mio amico, Patrick Karcher , ti chiedo per favore di non scrivere nulla che possa essere offensivo per qualcuno, come hai scritto, "• Inoltre, le chiavi esterne devono essere nominate in modo coerente in tabelle diverse. Dovrebbe essere legale picchiare qualcuno che non lo fa Fai questo.". Non ho mai fatto questo errore, amico mio Patrick, ma scrivo in generale. E se hanno in programma di batterti per questo? :)


2
Quindi stai dicendo che la tabella è l'entità? O la riga nella tabella è l'entità? Per me una tabella è una raccolta di righe, quindi una raccolta di entità che implica il plurale.
Jason,

4

Molto tardi alla festa, ma volevo ancora aggiungere i miei due centesimi sui prefissi delle colonne

Sembrano esserci due argomenti principali per l'utilizzo dello standard di denominazione table_column (o tableColumn) per le colonne, entrambi basati sul fatto che il nome della colonna stessa sarà univoco nell'intero database:

1) Non è necessario specificare sempre nomi di tabella e / o alias di colonna nelle query

2) Puoi facilmente cercare l'intero codice per il nome della colonna

Penso che entrambi gli argomenti siano imperfetti. La soluzione per entrambi i problemi senza utilizzare i prefissi è semplice. Ecco la mia proposta:

Usa sempre il nome della tabella nel tuo SQL. Ad esempio, utilizzare sempre table.column anziché la colonna.

Risolve ovviamente 2) poiché ora puoi solo cercare table.column anziché table_column.

Ma posso sentirti urlare, come risolve 1)? Si trattava esattamente di evitare questo. Sì, lo era, ma la soluzione era orribilmente imperfetta. Perché? Bene, la soluzione del prefisso si riduce a:
Per evitare di dover specificare table.column quando c'è ambiguità, dai un nome a tutte le tue colonne table_column!
Ma questo significa che d'ora in poi dovrai SEMPRE scrivere il nome della colonna ogni volta che specifichi una colonna. Ma se devi farlo comunque, qual è il vantaggio di scrivere sempre table.column in modo esplicito? Esatto, non ci sono vantaggi, è lo stesso numero esatto di caratteri da digitare.

modifica: sì, sono consapevole che la denominazione delle colonne con il prefisso impone l'utilizzo corretto mentre il mio approccio si basa sui programmatori


1
Come hai detto, non puoi fare affidamento su ogni caso con table.column. I programmatori dimenticheranno in un unico posto e quindi la tua ricerca e sostituzione globale ha appena interrotto l'intero programma. Oppure la renderai una regola e qualcuno penserà che sta rispettando la regola usando un alias del tavolo, sventando così di nuovo una scoperta globale. Inoltre, se vuoi organizzare il tuo codice con una sorta di classe di database (che sarà un buon programmatore), ci saranno momenti in cui passerai semplicemente il nome di una colonna a una funzione db o avrai solo il nome della colonna in una variabile.
dallin

2
@janb: sostengo totalmente la tua risposta. Voglio anche aggiungere che l'uso della ricerca di testo per trovare dipendenze è un modo barbaro per navigare nel codice. Una volta che le persone si sbarazzeranno di quella pratica di ricerca barbara, inizieranno a usare una buona denominazione, che è table.column. Quindi il problema non è lo stile dei nomi, il problema è che i cattivi strumenti sono fatti per i barbari.
alpav,

Il tuo argomento è difettoso. Il problema è che funziona in entrambi i modi e non aggiunge alcun vantaggio. Dici, per risolvere questo, scrivi sempre table.column, poiché stai già scrivendo table_column. Bene, puoi anche solo scrivere table_column perché stai già scrivendo table.column. In altre parole, non c'è differenza tra la tua risposta se non quella di introdurre possibili errori e non applicare convenzioni. È la ragione per cui abbiamo una parola chiave "privata". Potremmo fidarci che i programmatori utilizzino sempre correttamente le variabili di classe, ma la parola chiave la impone ed elimina possibili errori.
dallin

3

Convenzioni di denominazione (e stile) del database essenziale (fare clic qui per una descrizione più dettagliata)

i nomi delle tabelle scelgono nomi brevi e non ambigui, l'uso di non più di una o due parole per distinguere le tabelle facilita facilmente la denominazione di nomi di campi univoci così come la ricerca e il collegamento delle tabelle dà alle tabelle nomi singolari, mai plurali (aggiornamento: sono ancora d'accordo con i motivi indicati per questa convenzione, ma alla maggior parte delle persone piacciono molto i nomi di tabella plurale, quindi ho ammorbidito la mia posizione) ... segui il link sopra per favore


1
anche se ciò che Oracle suggerisce totalmente opposto al link linke sopra. scopri cosa dice Oracle qui .. ss64.com/ora/syntax-naming.html
AZ_


La convenzione di denominazione di Oracle è stata la più divertente di tutte .. e.g. PATIENTS would have a primary key called pa_patient_id_pk!!
nawfal,

2

I nomi delle tabelle sono singolari. Diciamo che stavi modellando una realtà tra qualcuno e il suo indirizzo. Ad esempio, se stai leggendo un modello di dati preferiresti "ogni persona può vivere a 0,1 o più indirizzi". o "ogni persona può vivere a 0,1 o più indirizzi". Penso che sia più facile pluralizzare l'indirizzo, piuttosto che riformulare le persone come persona. Inoltre i nomi collettivi sono abbastanza spesso dissimili alla versione singolare.


-4

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

Queste sono le convenzioni che mi hanno insegnato, ma dovresti adattarti a qualunque cosa usi il tubo flessibile di sviluppo.

  1. Plurale. È una raccolta di entità.
  2. Sì. L'attributo è una rappresentazione della proprietà singolare di un'entità.
  3. Sì, il nome della tabella dei prefissi consente una denominazione facilmente tracciabile di tutti gli indici dei vincoli e gli alias delle tabelle.
  4. Pascal Case per nomi di tabelle e colonne, prefisso + ALL maiuscole per indici e vincoli.

6
ChristianName ... questa è una strana convenzione.
BobbyShaftoe,

3
Numeri di serie sui tuoi tavoli? C'è qualcuno che seriamente pensare questo ha un senso lavori per gli sviluppatori?
ErikE,

Dal momento che questo esempio lo ha sollevato ... Sono personalmente contrario a mettere in rilievo gli acronimi nei nomi di tabelle o colonne, poiché penso che sia più difficile da leggere. Quindi, in questo caso, direi che StudentId è preferibile a StudentID. Non è un grosso problema quando l'acronimo è alla fine, ma ho visto innumerevoli esempi nel mio lavoro in cui gli acronimi erano in primo piano o al centro del nome, e ha reso più difficile analizzare la tua mente. Esempio: StudentABCSSN vs StudentAbcSsn.
redOctober13
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.