Quale standard devo seguire quando nomina nomi di tabelle e viste?

20

Quale standard devo seguire quando nomina nomi di tabelle e viste? Ad esempio, è una buona idea mettere qualcosa come tbl_ all'inizio dei nomi delle tabelle? Devo designare tabelle di codice / ricerca in qualche modo come ct_, lut_ o codes_? Ci sono altre cose da fare / da non fare?

Sto usando MS SQL Server e ho molti database con molte tabelle, quindi sarebbe bello avere qualcosa che possiamo usare come standard con qualche supporto razionale.

relational-theory naming-convention

— Beth Whitezel
fonte

29

OK, prima non metti MAI tbl davanti al nome di una tabella. È un tavolo, già adesso. Si chiama Notazione ungherese e la gente ha smesso di farlo 5+ anni fa.

Basta chiamare l'oggetto in base a ciò che è. Se una tabella contiene i dati dei dipendenti, chiamali "Dipendente". Se contiene informazioni sui computer, chiamalo "Computer". Se associa i computer ai dipendenti, chiamalo "EmployeeComputer" o "ComputerEmployee" (personalmente preferisco "EmployeeComputer").

Non esiste una vera convenzione di denominazione corretta da utilizzare (oltre a non utilizzare la notazione ungherese). Finché i nomi degli oggetti hanno senso che è importante.

— mrdenny
fonte

11

Inoltre, ti preghiamo di non mettere i nomi delle tabelle come nomi plurali, poiché ho visto esempi di impiegati, cumputer .. Sappiamo tutti che le tabelle dovrebbero avere molte righe, non una ..

— Marian

1

Perché dovresti creare viste di una tabella? Tutta una vista è, è un'istruzione select memorizzata. I dati non si materializzano dietro una vista a meno che non si stia utilizzando una vista indicizzata. Praticamente non uso mai le viste, mai. Certamente non c'è alcun vantaggio in termini di prestazioni nel farlo.

— mrdenny,

2

Usiamo le viste quando vogliamo fare qualcosa come unire un paio di tabelle o tradurre valori di codice in valori leggibili dall'uomo. La seconda situazione è quella in cui finiresti con un nome semplice.

— Beth Whitezel,

2

La risposta di Mr. Denny e i seguenti collaboratori sono supportati da questo: dba4life.blogspot.com/2007/11/…

1

@Marian: utilizzo i plurali perché rendono le query più naturali e risolvono le collisioni con le parole chiave. Molti sistemi con cui ho lavorato hanno avuto un'entità ordine. Utilizzando plurali rende il nome della tabella ordersnon ordere evita di dover citare il nome della tabella ogni volta che si tratta di utenti. Questo vale anche per groupe altre parole chiave. Fortunatamente, poche parole chiave si scontrano con entità comuni.

— BillThor l'

13

Usiamo schemi (pensiamoli forse come spazi dei nomi in SQL) sia per le autorizzazioni che per il raggruppamento. Quindi invece di "tbl" ecc

Data.Thing
Data.ThingHistory
Data.Stuff

Nessun codice va nello schema dei dati. Nessuna tabella vive al di fuori dello schema dati. Questo può ovviamente prolungarsi per avere uno schema di Ricerca o Staging, se lo si desidera.

Per le viste che usiamo, vwma questo era per distinguerle dalle tabelle in SQL Server 2000 ed è un po 'legacy ora

— GBN
fonte

3

+1 per raccomandare schemi. Ciò sarà utile mantenendo un grande db con centinaia di tabelle. Usiamo schemi anche per raggruppamenti funzionali .. come in AdventureWorks db

— CoderHawk

5

Personalmente sono un grande fan del Fanö Bedingung , nel senso che qui non è permesso che il nome sia l'inizio di un altro nome valido.

E in secondo luogo la distanza di Hamming tra due nomi è meglio di una lettera diversa.

Sì, sono regole dai tempi predigitali, ma semplificano la vita.

E i nomi di terzi devono essere pronunciabili, o diventerai pazzo, quando il riconoscimento vocale diventerà vero.

— bernd_k
fonte

2

Quando il riconoscimento vocale diventa vero, sarò comunque matto. :-)

— Beth Whitezel

Solo se supporti Telethon

— bernd_k

1

Quando arriverà il riconoscimento vocale, diventerò un camionista. Quello o un pazzo eremita.

— mrdenny l'

Potresti spiegare più in dettaglio (forse con un esempio) che cos'è "Fano Bedingung"?

— Nick Chammas,

1

@NickChammas Penso che in inglese chiamiamo questo codice Shannon-Fano .

— Iain Samuel McLean Elder,

2

Non so che ci sia davvero una convenzione di denominazione "migliore" là fuori, in quanto si riduce davvero alle preferenze personali e alla facilità di sviluppo. Il mio consiglio è di scegliere una convenzione di denominazione e aderirvi. Se si desidera separare le parole con un carattere di sottolineatura, farlo in tutti gli oggetti del database. Se si desidera utilizzare camelCase, farlo in tutti gli oggetti del database.

Nel mio negozio aderiamo alle seguenti regole:

Separiamo le parole con caratteri di sottolineatura e usiamo tutte le lettere minuscole.
I nomi delle nostre tabelle descrivono cosa sono: dbo.person, dbo.invoice.
I nostri nomi di tabelle molti-a-molti descrivono anche cosa sono (con l'aggiunta di mm per indicare una relazione molti-a-molti da mappare: dbo.person_mm_address. Le nostre procedure memorizzate definite dall'utente descrivono sia l'oggetto che l'azione eseguita: usp_person_select , usp_address_select_by_city Le nostre viste e funzioni seguono le stesse regole delle procedure memorizzate I nostri indici includono tabella, colonne chiave (in ordine) e un'indicazione di cluster / non cluster: ix_person_last_name_first_name_nc

Solo perché questo è ciò che usiamo nel mio negozio, ciò non significa che queste regole siano adatte a te. Scegli qualcosa che tu e il tuo team di sviluppo concordate sia utile e facile da sviluppare, e instaurate una cultura della conoscenza e dell'uso di qualunque convenzione di denominazione decida. Nel nostro caso, ciò include la revisione del codice per tutti gli oggetti creati in un database. Nel corso del tempo, la combinazione di una convenzione di denominazione documentata e di una revisione del codice inter pares ha portato a sempre meno deviazioni dalla convenzione.

Spero che questa "non risposta" aiuti in qualche modo.

— Matt M
fonte

2

Sono contento di questi da anni

nomi delle tabelle: maiuscoletti e caratteri di sottolineatura, singolare {cliente, prodotto}
nomi di tabella per molte o molte relazioni: tablename1_tablename2: {customer_product}
visualizzazioni: maiuscoletti aggiunti v alla fine {customerv, productv, product_groupv}
acquisti memorizzati: nome e funzione della tabella {customer_select, customer_insert, customer_delete, customer_update}

se hai un pacchetto di hosting condiviso economico, dovrai usare l'abbreviazione del progetto davanti a tutti i tuoi oggetti, come ad esempio sito degli amministratori di database, da_users, da_questions

— Uğur Gümüşhan
fonte

Perché product_groupve non product_group_vper le viste (se insisti su questa distinzione di viste e tabelle)?

— ypercubeᵀᴹ

@ypercube perché sono troppo pigro per digitare un carattere di sottolineatura aggiuntivo e commetto facilmente errori di battitura. Leggo le parole più facilmente quando uso un trattino basso e uso v per separare la vista dalle tabelle, e v non è una parola, quindi non uso il trattino basso. Sembra incoerente, sì, ma trovo pratico questo formato.

— Uğur Gümüşhan,