Jakiego standardu należy przestrzegać, nazywając tabele i widoki?

20

Jakiego standardu należy przestrzegać, nazywając tabele i widoki? Na przykład, czy dobrym pomysłem jest umieszczenie czegoś takiego jak tbl_ na początku nazw tabel? Czy powinienem wyznaczyć tabele kodów / odnośników w taki sposób, jak ct_, lut_ lub code_? Czy są jeszcze jakieś nakazy / zakazy?

Korzystam z MS SQL Server i mam wiele baz danych z wieloma tabelami, więc byłoby miło mieć coś, czego moglibyśmy użyć jako standardu z niektórymi wspierającymi racjonalnymi.

relational-theory naming-convention

— Beth Whitezel
źródło

29

OK, najpierw NIGDY nie umieszczaj tbl przed nazwą tabeli. To jest stół, my już to. To się nazywa notacja węgierska, a ludzie przestali to robić ponad 5 lat temu.

Po prostu wywołaj obiekt na podstawie tego, co to jest. Jeśli tabela zawiera dane pracownika, nazwij go „Pracownik”. Jeśli zawiera informacje o komputerach, nazwij to „Komputer”. Jeśli mapuje komputery na pracowników, nazwij to „EmployeeComputer” lub „ComputerEmployee” (osobiście bardziej podoba mi się „EmployeeComputer”).

Nie ma żadnej właściwej konwencji nazewnictwa (z wyjątkiem nie używania notacji węgierskiej). Tak długo, jak nazwy obiektów mają sens, że jest to ważne.

— mrdenny
źródło

11

Ponadto nie należy umieszczać nazw tabel jako rzeczowników w liczbie mnogiej, ponieważ widziałem przykłady pracowników, Cumputers. Wszyscy wiemy, że tabele powinny mieć wiele wierszy, a nie jeden

— Marian

1

Dlaczego miałbyś tworzyć widoki tabeli? Cały widok to przechowywana instrukcja select. Dane nie są zmaterializowane za widokiem, chyba że używasz widoku indeksowanego. Prawie nigdy nie używam widoków, nigdy nie mam. Z pewnością nie przynosi to żadnych korzyści w zakresie wydajności.

— mrdenny,

2

Używamy widoków, gdy chcemy zrobić coś takiego jak połączyć kilka tabel lub przetłumaczyć wartości kodu na wartości czytelne dla człowieka. Druga sytuacja to ta, w której skończyłbyś z prostą nazwą.

— Beth Whitezel,

2

Odpowiedź pana Denny'ego i następujących autorów jest wspierana przez: dba4life.blogspot.com/2007/11/…

1

@Marian: Używam liczby mnogiej, ponieważ sprawiają, że zapytania czytają bardziej naturalnie i rozwiązują kolizje ze słowami kluczowymi. Wiele systemów, z którymi pracowałem, ma jednostkę zamówienia. Używanie liczby mnogiej powoduje, że nazwa tabeli ordersnie jest, orderi unika się konieczności cytowania nazwy tabeli za każdym razem, gdy jest to użytkownik. Dotyczy to również groupi innych słów kluczowych. Na szczęście niewiele słów kluczowych koliduje ze wspólnymi bytami.

— BillThor

13

Używamy schematów (być może uważamy je za przestrzenie nazw w SQL) zarówno dla uprawnień, jak i grupowania. Więc zamiast „tbl” itd. Mamy

Data.Thing
Data.ThingHistory
Data.Stuff

Żaden kod nie wchodzi w schemat danych. Żadne tabele nie działają poza schematem danych. Można to oczywiście rozszerzyć o schemat wyszukiwania lub inscenizacji, jeśli chcesz.

Do widoków używamy, vwale miało to na celu odróżnienie ich od tabel w SQL Server 2000 i jest to już trochę spuścizna

— gbn
źródło

3

+1 za polecanie schematów. Będzie to przydatne przy zachowaniu dużego db ze 100 setkami tabel. Używamy również schematów do grupowania funkcjonalnego. Tak jak w AdventureWorks db

— CoderHawk

5

Osobiście jestem wielkim fanem Fanö Bedingung , co oznacza, że nie nazwa może być początkiem innego ważnego imienia.

Po drugie, odległość Hamminga między dwoma nazwami jest lepsza niż więcej niż jedna litera.

Tak, są to reguły z czasów drapieżnych, ale ułatwiają życie.

A trzecie imiona muszą być wymawiane, inaczej oszalejesz, gdy rozpoznawanie głosu stanie się prawdą.

— bernd_k
źródło

2

Kiedy rozpoznawanie głosu stanie się prawdą, i tak będę wściekły. :-)

— Beth Whitezel,

Tylko jeśli obsługujesz telethon

— bernd_k

1

Kiedy pojawi się rozpoznawanie głosu, zostanę kierowcą ciężarówki. To lub szalony pustelnik.

— mrdenny

Czy możesz wyjaśnić bardziej szczegółowo (być może z przykładem), co to jest „Fano Bedingung”?

— Nick Chammas,

1

@NickChammas Myślę, że po angielsku nazywamy to kodowaniem Shannon-Fano .

— Iain Samuel McLean Starszy

2

Nie wiem, czy istnieje jakaś najlepsza konwencja nazewnictwa, ponieważ sprowadza się ona do osobistych preferencji i łatwości rozwoju. Radzę wybrać konwencję nazewnictwa i stosować się do niej. Jeśli chcesz oddzielić słowa znakiem podkreślenia, zrób to we wszystkich obiektach bazy danych. Jeśli chcesz użyć camelCase, zrób to we wszystkich obiektach bazy danych.

W moim sklepie przestrzegamy następujących zasad:

Oddzielamy słowa podkreśleniami i używamy wszystkich małych liter.
Nazwy naszych tabel opisują, co to są: dbo.person, dbo.invoice.
Nasze nazwy tabel wiele do wielu opisują również, jakie są (z dodatkiem mm aby wskazać mapowanie relacji wiele do wielu: dbo.person_mm_address. Nasze zdefiniowane przez użytkownika procedury składowane opisują zarówno obiekt, jak i wykonywaną akcję: usp_person_select , usp_address_select_by_city Nasze widoki i funkcje są zgodne z tymi samymi regułami, co procedury składowane. Nasze indeksy obejmują tabelę, kolumny kluczy (w kolejności) oraz oznaczenie klastrów / nieklastrów: ix_person_last_name_first_name_nc

Tylko dlatego, że używamy tego w moim sklepie, nie oznacza to, że te zasady są dla Ciebie odpowiednie. Wybierz coś, co Ty i Twój zespół programistów zgadzają się, że jest zarówno użyteczne, jak i łatwe do rozwijania, i ustal kulturę poznania i korzystania z dowolnej konwencji nazewnictwa, którą wybierzesz. W naszym przypadku obejmuje to przegląd kodu dla wszelkich obiektów utworzonych w bazie danych. Z czasem połączenie udokumentowanej konwencji nazewnictwa i przeglądu kodu równorzędnego doprowadziło do coraz mniejszych odchyleń od konwencji.

Mam nadzieję, że to „brak odpowiedzi” w jakiś sposób pomoże.

— Matt M.
źródło

2

Jestem z nich zadowolony od lat temu

nazwy tabel: małe czapki i podkreślenia, liczba pojedyncza {klient, produkt}
nazwy tabel dla relacji wiele do wielu: tablename1_tablename2: {klient_produkt}
wyświetlenia: małe litery dodane na końcu {customerv, productv, product_groupv}
przechowywane procedury: nazwa tabeli i funkcja {customer_select, customer_insert, customer_delete, customer_update}

jeśli masz tani współużytkowany pakiet hostingowy, musisz użyć skrótu projektu przed wszystkimi swoimi obiektami, takimi jak na przykład witryna administratorów baz danych, użytkownicy_ da_użytkownicy, pytania_ da_questions

— Uğur Gümüşhan
źródło

Dlaczego product_groupvi nie product_group_vdla widoków (jeśli nalegasz na to rozróżnienie widoków i tabel)?

— ypercubeᵀᴹ

@ypercube, ponieważ jestem zbyt leniwy, aby wpisać jeden dodatkowy znak podkreślenia i łatwo popełniam błędy pisarskie. Czytam te słowa łatwiej, kiedy używam podkreślenia i używam v do oddzielania widoku od tabel, i v nie jest słowem, więc nie używam podkreślenia. Wygląda to niekonsekwentnie, tak, ale uważam ten format za praktyczny.

— Uğur Gümüşhan