practice - Convenzioni di denominazione di database, tabelle e colonne?




sql server naming conventions (16)

  1. No. Una tabella deve essere denominata in base all'entità che rappresenta. La persona, non le persone, è come ti riferiresti a chiunque rappresenti uno dei dischi.
  2. Di nuovo, stessa cosa. La colonna FirstName in realtà non dovrebbe essere chiamata FirstNames. Dipende tutto da cosa vuoi rappresentare con la colonna.
  3. NO.
  4. Sì. Affidalo per chiarezza. Se è necessario disporre di colonne come "FirstName", il case renderà più semplice la lettura.

Ok. Questo è il mio $ 0,02

Ogni volta che progetto un database, mi chiedo sempre se c'è un modo migliore di nominare un oggetto 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. Dovrei prefisso tabelle o colonne?
  4. Dovrei usare qualsiasi caso nella denominazione degli articoli?

Ci sono delle linee guida raccomandate là fuori per nominare gli articoli in un database?


  1. Sicuramente mantenere singolari i nomi delle tabelle, persone non persone
    1. Anch'io
    2. No. Ho visto alcuni prefissi terribili, arrivando al punto di dire 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 dei miei tavoli



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

  1. Qualsiasi standard di denominazione è migliore di nessun standard.
  2. Non esiste uno standard "unico", tutti abbiamo le nostre preferenze
  3. Se c'è già uno standard, usalo. Non creare un altro standard o infangare gli standard esistenti.

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

Per i campi ci si aspetterebbe che i nomi dei campi includessero il prefisso / acryonm della tabella (ad es. Cust_address1) e preferiamo anche l'uso di un set standard di suffissi (_id per PK, _cd per "code", _nm per "nome ", _nb per" numero ", _dt per" Data ").

Il nome del campo chiave Foriegn dovrebbe essere lo stesso del 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

Quando sviluppo un nuovo progetto, ti consiglio di scrivere tutti i nomi delle entità preferite, i prefissi e gli acronimi e di dare questo documento ai tuoi sviluppatori. Quindi, quando decidono di creare una nuova tabella, possono fare riferimento al documento piuttosto che "indovinare" a cosa devono essere chiamati la tabella e i campi.


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 implementata 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 si adatta facilmente ai cambiamenti durante la fase più lunga e più importante del ciclo di vita del software: la gestione dei servizi in produzione.

Ecco le mie risposte:

  1. Sì, i nomi delle tabelle dovrebbero essere plurali quando si riferiscono a un insieme di negoziazioni , titoli o controparti, ad esempio.
  2. Sì.
  3. Sì. Le tabelle SQL sono precedute da tb_, le viste sono prefissate da vw_, le stored procedure sono precedute da usp_ e i trigger sono preceduti da tg_ seguito dal nome del database.
  4. Il nome della colonna deve essere in minuscolo separato dal trattino di sottolineatura.

La denominazione è difficile, ma in ogni organizzazione c'è qualcuno che può nominare le cose e in ogni gruppo di software dovrebbe esserci qualcuno che si assume la responsabilità degli standard dei nomi e assicura 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 di denominazione e standard:

  • Utilizza la lingua del tuo cliente e il dominio della tua soluzione
  • Essere descrittivo
  • Sii coerente
  • Disambigui, rifletti e refactoring
  • Non usare abbreviazioni a meno che non siano chiare per tutti
  • Non utilizzare parole chiave riservate SQL come nomi di colonne

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 stesso sarà univoco nell'intero database:

1) Non è necessario specificare nomi di tabelle e / o alias di colonne nelle query per tutto il tempo

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

Penso che entrambi gli argomenti siano difettosi. La soluzione per entrambi i problemi senza l'utilizzo di prefissi è semplice. Ecco la mia proposta:

Usa sempre il nome della tabella nel tuo SQL. Ad esempio, usa sempre table.column invece di column.

Ovviamente risolve 2) come ora puoi semplicemente cercare table.column invece di 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'è un'ambiguità, date un nome a tutte le vostre 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 rispetto a scrivere sempre table.column in modo esplicito? Esattamente, non c'è alcun vantaggio, è lo stesso numero esatto di caratteri da digitare.

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


Ok, visto che stiamo valutando l'opinione:

Credo che i nomi delle tabelle dovrebbero essere plurali. Le tabelle sono una raccolta (una tabella) di entità. Ogni riga rappresenta una singola entità e la tabella rappresenta la raccolta. Quindi chiamerei un tavolo di persone Entità Persone (o Persone, qualunque sia la tua fantasia).

Per coloro che amano vedere singolari "nomi di entità" nelle query, è quello che userei alias di tabella per:

SELECT person.Name
FROM People person

Un po 'come LINQ "dalla persona nelle persone seleziona person.Name".

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


Risposta tardiva qui, ma in breve:

  1. La mia preferenza è plurale
  2. Tabelle : * Solitamente * nessun prefisso è il migliore. Colonne : n.
  3. Entrambe le tabelle e le 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 tue chiavi primarie usando il formato "[singularOfTableName] ID". In altre parole, se il nome della tabella è Cliente o Clienti , la chiave primaria deve essere CustomerID .
  • Inoltre, le chiavi esterne devono essere denominate in modo coerente in tabelle diverse. Dovrebbe essere legale picchiare qualcuno che non lo fa. Vorrei sottolineare che, sebbene i vincoli delle chiavi esterne siano spesso importanti, la costante denominazione 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. Se il tuo tavolo per i clienti è chiamato Clienti o Cliente è meno importante di quello che fai nello stesso modo nello stesso database. E puoi lanciare una moneta per determinare come utilizzare i trattini bassi, ma 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 identificati come identici. Non avere Zip su un tavolo e ZipCode su un altro.
  • Per separare le parole nei nomi della tabella o della colonna, utilizzare PascalCasing. Usare CamelCasing non sarebbe intrinsecamente problematico, ma non è la convenzione e sembrerebbe divertente. Tratterò i caratteri di sottolineatura in un attimo. (Non puoi usare ALLCAPS come nei 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 sono un passatempo dai tempi più bui, più selvaggi. Cus_AddRef. Che diavolo è? Riferimento destinatario custodiale? Rimborso aggiuntivo del cliente? Referral indirizzi personalizzati?

(3) Cosa dovresti considerare.

  • Penso davvero che dovresti avere nomi plurali per le tabelle; alcuni pensano singolari. Leggi gli argomenti altrove. I nomi delle colonne dovrebbero essere singolari comunque. Anche se si utilizzano nomi di tabelle plurali, le tabelle che rappresentano combinazioni di altre tabelle potrebbero essere al singolare. Ad esempio, se hai una promozione e una tabella articoli , una tabella che rappresenta un elemento che fa parte di una promozione potrebbe essere Promotions_Items, ma potrebbe anche essere legittimamente oggetto promozionale che penso (rispecchiando la relazione uno-a-molti).
  • Utilizzare i caratteri di sottolineatura in modo coerente e per uno scopo particolare. Solo i nomi delle tabelle generali dovrebbero essere abbastanza chiari con PascalCasing; non hai bisogno di caratteri di sottolineatura 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 migliore. Nel tuo primo db o due, non suggerirei di usare prefissi per il raggruppamento tematico generale di tabelle. Le tabelle finiscono per non adattarsi facilmente alle tue categorie e in effetti può rendere più difficile trovare tabelle. Con l'esperienza, è possibile pianificare e applicare uno schema di prefisso che fa più bene che male. Ho lavorato in un db una volta in cui le tabelle dati iniziarono con tbl , le tabelle di configurazione con ctbl , le viste con vew , proc's sp e udf's fn e alcune altre; è stato meticolosamente applicato in modo coerente, quindi ha funzionato bene. L'unica volta in cui si ha bisogno dei prefissi è quando si hanno soluzioni realmente separate che per qualche motivo risiedono nello stesso db; il loro prefisso può essere molto utile per raggruppare le tabelle. Il prefisso va bene anche per situazioni speciali, come per i tavoli temporanei che vuoi distinguere.
  • Molto raramente (se mai) vorresti anteporre le colonne.

Secondo me:

  1. I nomi delle tabelle dovrebbero essere plurali.
  2. I nomi delle colonne dovrebbero essere singolari.
  3. No.
  4. CamelCase (il mio preferito) o underscore_separated per entrambi i nomi di tabelle e nomi di colonne.

Tuttavia, come è stato detto, qualsiasi convenzione è meglio di nessuna convenzione. Indipendentemente da come scegli di farlo, documentalo in modo che le future modifiche seguano le stesse convenzioni.


So che è tardi per il gioco, e la domanda ha già avuto una risposta molto buona, ma voglio esprimere la mia opinione sul n. 3 in merito al prefisso dei nomi delle colonne.

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

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

Quando fui presentato per la prima volta con questo standard, ero assolutamente contrariato; Ho odiato l'idea. Non sopportavo l'idea di tutta quella tipizzazione e ridondanza in più. Ora ne ho avuto abbastanza esperienza che non tornerò mai più.

Il risultato di ciò è che tutte le colonne nello schema del database sono uniche. C'è un grande vantaggio in questo, che supera tutti gli argomenti contro di esso (a mio parere, ovviamente):

Puoi cercare l'intero codice base e trovare in modo affidabile ogni riga di codice che tocca una determinata colonna.

Il vantaggio di # 1 è incredibilmente enorme. Posso deprecare una colonna e sapere esattamente quali file devono essere aggiornati prima che la colonna possa essere rimossa in sicurezza 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 parte del sistema. Non riesco a contare il numero di volte in cui questo ha trasformato un progetto potenzialmente enorme in uno semplice, né il numero di ore che abbiamo risparmiato nel lavoro di sviluppo.

Un altro vantaggio relativamente minore è che devi solo usare gli alias di tabella quando fai un auto 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%';

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

Vedi il nome dell'elemento Data su Wikipedia :

"Le tabelle sono raccolte di entità e seguono le linee guida per la denominazione della raccolta: idealmente, viene utilizzato un nome collettivo: ad es., Personale.Il plurale è anche corretto: Dipendenti I nomi errati includono: dipendente, tblEmployee e EmployeeTable."

Come sempre, ci sono delle 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, allora fai un business case per cambiarlo piuttosto che essere il ranger solitario.


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

i nomi delle tabelle scelgono nomi brevi e non ambigui, utilizzando non più di una o due parole distinguono le tabelle facilita facilmente la denominazione di nomi di campi univoci così come le tabelle di ricerca e collegamento danno tabelle nomi singolari, mai plurali (aggiornamento: sono ancora d'accordo con le ragioni fornite per questa convenzione, ma alla maggior parte della gente piacciono i nomi di tavoli plurali, quindi ho attenuato la mia posizione ... segui il link sopra per favore


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 solo singolare, quindi trasmetterà che manterrà un valore atomico e confermerà la teoria della normalizzazione. Se tuttavia, ci sono n numero dello stesso tipo di proprietà, allora dovrebbero essere suffissi con 1, 2, ..., n, ecc.

Prefixing Tabelle / Colonne: è un argomento enorme, discuterà più avanti.

Involucro: dovrebbe essere un caso Camel

Amico mio, Patrick Karcher , ti chiedo di compiacere di non scrivere nulla che possa essere offensivo per qualcuno, come hai scritto, "• Inoltre, le chiavi esterne devono essere nominate coerentemente in tabelle diverse. Dovrebbe essere legale picchiare qualcuno che non Fai questo.". Non ho mai fatto questo errore, mio ​​amico Patrick, ma sto scrivendo in generale. E se insieme avessero intenzione di batterti per questo? :)



--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 sono state insegnate, ma dovresti adattarti a qualsiasi tipo di utilizzo del tubo 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 di prefisso consente una denominazione facilmente rintracciabile di tutti gli indici di vincoli e alias di tabella.
  4. Caso Pascal per nomi di tabelle e colonne, prefisso + TUTTI maiuscole per indici e vincoli.

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






naming-conventions