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

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.

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.

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

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ą.

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.

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