Konwencje nazewnictwa baz danych, tabel i kolumn? [Zamknięte]

Ilekroć projektuję bazę danych, zawsze zastanawiam się, czy istnieje najlepszy sposób nazywania elementu w mojej bazie danych. Dość często zadaję sobie następujące pytania:

1. Czy nazwy tabel powinny być w liczbie mnogiej?
2. Czy nazwy kolumn powinny być pojedyncze?
3. Czy powinienem prefiksować tabele lub kolumny?
4. Czy powinienem używać nazwy w nazwach przedmiotów?

Czy istnieją jakieś zalecane wytyczne dotyczące nazewnictwa elementów w bazie danych?

Polecam sprawdzenie przykładowych baz danych Microsoft SQL Server: https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

W przykładzie AdventureWorks zastosowano bardzo przejrzystą i spójną konwencję nazewnictwa, która używa nazw schematów do organizacji obiektów bazy danych.

1. Nazwy osobliwe dla tabel
2. Nazwy osobliwe dla kolumn
3. Nazwa schematu dla prefiksu tabel (np .: SchemeName.TableName)
4. Obudowa Pascal (inaczej górna obudowa wielbłąda)

Spóźniona odpowiedź tutaj, ale w skrócie:

1. Moje preferencje to liczba mnoga
2. tak
3. Tabele : * Zwykle * najlepsze są żadne prefiksy. Kolumny : Nie
4. Zarówno tabele, jak i kolumny: PascalCase.

Opracowanie:

(1) Co musisz zrobić. Za każdym razem jest niewiele rzeczy, które musisz zrobić w określony sposób, ale jest kilka.

• Nazwij swoje klucze podstawowe, używając formatu „[singularOfTableName] ID”. Oznacza to, że niezależnie od tego, czy nazwa Twojej tabeli to Klient czy Klienci , kluczem podstawowym powinien być CustomerID .
• Ponadto klucze obce muszą być konsekwentnie nazywane w różnych tabelach. Pobicie kogoś, kto tego nie robi, powinno być legalne. Chciałbym twierdzić, że chociaż zdefiniowane ograniczenia klucza obcego są często ważne, spójne nazewnictwo klucza obcego jest zawsze ważne
• Baza danych musi mieć wewnętrzne konwencje . Choć w późniejszych sekcjach zobaczysz mnie jest bardzo elastyczny, w terminie do nazewnictwa bazy danych musi być bardzo spójne. To, czy twoja tabela dla klientów nosi nazwę Klienci, czy Klient jest mniej ważne niż to, że robisz to w ten sam sposób w tej samej bazie danych. Możesz rzucić monetą, aby określić sposób użycia podkreślników, ale musisz nadal używać ich w ten sam sposób . Jeśli tego nie zrobisz, jesteś złym człowiekiem, który powinien mieć niską samoocenę.

(2) Co prawdopodobnie powinieneś zrobić.

• Pola reprezentujące ten sam rodzaj danych w różnych tabelach powinny mieć takie same nazwy. Nie używaj Zip na jednym stole, a ZipCode na drugim.
• Aby oddzielić słowa w nazwach tabel lub kolumn, użyj PascalCasing. Korzystanie z camelCasing nie byłoby z natury problematyczne, ale nie jest to konwencja i wyglądałoby śmiesznie. Za chwilę zajmę się podkreśleniami. (Nie możesz używać ALLCAPS jak za dawnych czasów. OBNOXIOUSTABLE.ANNOYING_COLUMN było w DB2 w porządku 20 lat temu, ale nie teraz.)
• Nie sztucznie skracaj ani nie skracaj słów. Lepiej, aby nazwa była długa i jasna niż krótka i myląca. Ultrakrótkie nazwy to pozostałość po mrocznych, bardziej dzikich czasach. Cus_AddRef. Co to jest u licha? Numer referencyjny adresata? Dodatkowy zwrot dla klienta? Niestandardowe skierowanie adresu?

(3) Co powinieneś rozważyć.

• Naprawdę uważam, że powinieneś mieć liczbę mnogą dla tabel; niektórzy myślą pojedynczo. Przeczytaj argumenty w innym miejscu. Nazwy kolumn powinny być jednak pojedyncze. Nawet jeśli użyjesz wielu nazw tabel, tabele reprezentujące kombinacje innych tabel mogą znajdować się w liczbie pojedynczej. Na przykład, jeśli masz tabelę Promocji i Przedmiotów , tabelą reprezentującą przedmiot będący częścią promocji może być Promotions_Items, ale moim zdaniem może to być również uzasadniona promocja_Items (odzwierciedlająca relację jeden do wielu).
• Używaj podkreślników konsekwentnie i do określonego celu. Tylko ogólne nazwy tabel powinny być wystarczająco jasne w PascalCasing; nie potrzebujesz podkreślników do oddzielania słów. Zapisz podkreślenia albo (a), aby wskazać tabelę asocjacyjną, lub (b) do prefiksu, który omówię w następnym punkcie.
• Prefiks nie jest ani dobry, ani zły. To zwykle nie jest najlepsza. W pierwszym lub dwóch db nie sugerowałbym używania prefiksów do ogólnego grupowania tematycznego tabel. Tabele ostatecznie nie pasują do twoich kategorii i może to utrudnić znalezienie tabel. Dzięki doświadczeniu możesz zaplanować i zastosować schemat prefiksowania, który przynosi więcej korzyści niż szkód. Pracowałem w db raz gdzie tabele danych rozpoczął się tbl , config tabele z ctbl , widoki z vew , Proc w sp i UDF fni kilka innych; był skrupulatnie, konsekwentnie stosowany, więc działał dobrze. POTRZEBUJESZ tylko tych prefiksów, kiedy masz naprawdę osobne rozwiązania, które z jakiegoś powodu znajdują się w tej samej bazie danych; ich prefiks może być bardzo pomocny w grupowaniu tabel. Prefiks jest również odpowiedni w szczególnych sytuacjach, takich jak tabele tymczasowe, które chcesz się wyróżnić.
• Bardzo rzadko (jeśli w ogóle) chciałbyś prefiksować kolumny.

Ok, ponieważ rozważamy opinię:

Uważam, że nazwy tabel powinny być w liczbie mnogiej. Tabele są zbiorem (tabelą) encji. Każdy wiersz reprezentuje pojedynczy byt, a tabela reprezentuje kolekcję. Tak więc nazwałbym tabelę bytu Osoby Osobą (lub Osobą, cokolwiek ci się podoba).

Dla tych, którzy lubią widzieć w zapytaniach pojedyncze „nazwy jednostek”, użyłbym do tego aliasów tabel:

SELECT person.Name
FROM People person

Trochę jak LINQ „od osoby w osobach wybierz person.Name”.

Jeśli chodzi o 2, 3 i 4, zgadzam się z @Lars.

Pracuję w zespole wsparcia bazy danych z trzema bazami danych i nasze rozważane opcje to:

1. Każdy standard nazewnictwa jest lepszy niż żaden standard.
2. Nie ma „jednego prawdziwego” standardu, wszyscy mamy swoje preferencje
3. Jeśli istnieje już standard, użyj go. Nie twórz kolejnego standardu ani nie mętź istniejących standardów.

Używamy pojedynczych nazw dla tabel. Tabele zwykle mają prefiks nazwy systemu (lub jego akronimu). Jest to przydatne, jeśli kompleks systemu, ponieważ możesz zmienić prefiks, aby pogrupować tabele logicznie (tj. Reg_customer, reg_booking i regadmin_limits).

W przypadku pól spodziewalibyśmy się, że nazwy pól będą zawierać prefiks / acryonm tabeli (tj. Cust_address1), a także wolimy używać standardowego zestawu sufiksów (_id dla PK, _cd dla „kodu”, _nm dla „name” ”, _nb dla„ liczba ”, _dt dla„ Data ”).

Nazwa pola klucza Foriegn powinna być taka sama jak pola klucza podstawowego.

to znaczy

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

Podczas opracowywania nowego projektu zalecam zapisanie wszystkich preferowanych nazw encji, prefiksów i akronimów i przekazanie tego dokumentu swoim programistom. Następnie, decydując się na utworzenie nowej tabeli, mogą odwoływać się do dokumentu, zamiast „odgadnąć”, jak powinna się nazywać tabela i pola.

1. Nie. Tabelę należy nazwać po encji, którą reprezentuje. Osoba, a nie osoby to sposób, w jaki odnosiłbyś się do każdego, kto reprezentuje jeden z akt.
2. Znowu to samo. Kolumna FirstName naprawdę nie powinna nazywać się FirstNames. Wszystko zależy od tego, co chcesz reprezentować za pomocą kolumny.
3. NIE.
4. Tak. Obudź to dla jasności. Jeśli potrzebujesz kolumn takich jak „FirstName”, obudowa ułatwi czytanie.

Ok. To moje 0,02 $

Popieram także konwencję nazewnictwa w stylu ISO / IEC 11179, zauważając, że są one raczej wytycznymi niż nakazowymi.

Zobacz Nazwa elementu danych na Wikipedii :

„Tabele są kolekcjami jednostek i są zgodne z wytycznymi nazewnictwa kolekcji. Najlepiej jest używać nazwy zbiorczej: np. Personelu. Liczba mnoga jest również poprawna: pracownicy. Niepoprawne nazwy obejmują: pracownik, tblEmployee i EmployeeTable”.

Jak zawsze, istnieją wyjątki od reguł, np. Tabela, która zawsze ma dokładnie jeden wiersz, może być lepsza z pojedynczą nazwą, np. Tabela konfiguracji. A spójność ma ogromne znaczenie: sprawdź, czy Twój sklep ma konwencję, a jeśli tak, postępuj zgodnie z nią; jeśli ci się nie podoba, zrób uzasadnienie biznesowe, aby to zmienić, zamiast być samotnym łowcą.

Cały czas słyszę argument, że to, czy stół jest pluralizowany, zależy od osobistego gustu i nie ma najlepszej praktyki. Nie wierzę, że to prawda, szczególnie jako programista w przeciwieństwie do DBA. O ile mi wiadomo, nie ma uzasadnionych powodów, aby pluralizować nazwę tabeli inną niż „To po prostu ma sens, ponieważ jest to zbiór obiektów”, podczas gdy istnieją uzasadnione korzyści w kodzie dzięki posiadaniu pojedynczych nazw tabel. Na przykład:

1. Pozwala to uniknąć błędów i pomyłek spowodowanych wieloznacznością. Programiści nie są do końca znani ze swojej znajomości pisowni, a mnożenie niektórych słów jest mylące. Na przykład, czy liczba mnoga kończy się na „es”, czy tylko „s”? Czy to osoby czy ludzie? Podczas pracy nad projektem z dużymi zespołami może to stanowić problem. Na przykład instancja, w której członek zespołu używa niepoprawnej metody do tworzenia liczby mnogiej utworzonej przez siebie tabeli. Kiedy wchodzę w interakcję z tą tabelą, jest ona używana w całym kodzie, do którego nie mam dostępu lub którego naprawienie zajęłoby zbyt dużo czasu. Rezultat jest taki, że muszę pamiętać, aby za każdym razem, gdy go używam, źle przeliterować tabelę. Przydarzyło mi się coś bardzo podobnego do tego. Łatwiej jest dla każdego członka zespołu konsekwentnie i łatwo korzystać z dokładnych, popraw nazwy tabel bez błędów lub konieczności ciągłego wyszukiwania nazw tabel, tym lepiej. Wersja pojedyncza jest znacznie łatwiejsza w obsłudze w środowisku zespołowym.

2. Jeśli używasz pojedynczej wersji nazwy tabeli ORAZ przedrostek klucza podstawowego nazwą tabeli, masz teraz tę zaletę, że możesz łatwo określić nazwę tabeli na podstawie klucza podstawowego lub odwrotnie za pomocą samego kodu. Możesz otrzymać zmienną z nazwą tabeli, połączyć „Id” do końca, a teraz masz klucz podstawowy tabeli za pomocą kodu, bez konieczności wykonywania dodatkowego zapytania. Możesz też odciąć „Id” od końca klucza podstawowego, aby określić nazwę tabeli za pomocą kodu. Jeśli użyjesz „id” bez nazwy tabeli dla klucza podstawowego, nie możesz za pomocą kodu ustalić nazwy tabeli z klucza podstawowego. Ponadto większość osób, które pluralizują nazwy tabel i prefiksuje kolumny PK z nazwą tabeli, używa pojedynczej wersji nazwy tabeli w PK (na przykład statusy i status_id),

3. Jeśli uczynisz nazwy tabel pojedynczymi, możesz je dopasować do nazw klas, które reprezentują. Po raz kolejny może to uprościć kod i pozwolić ci robić naprawdę porządne rzeczy, takie jak tworzenie instancji klasy poprzez posiadanie tylko nazwy tabeli. To także sprawia, że ​​kod jest bardziej spójny, co prowadzi do ...

4. Jeśli nazwa tabeli będzie pojedyncza, spowoduje to, że schemat nazewnictwa będzie spójny, zorganizowany i łatwy do utrzymania w każdej lokalizacji. Wiesz, że w każdym przypadku w kodzie, czy to w nazwie kolumny, czy jako nazwa klasy, czy jako nazwa tabeli, jest to ta sama dokładna nazwa. Pozwala to na przeprowadzanie globalnych wyszukiwań, aby zobaczyć wszędzie, gdzie wykorzystywane są dane. Kiedy tworzysz liczbę mnogą nazwy tabeli, będą przypadki, w których użyjesz pojedynczej wersji tej nazwy tabeli (klasa, w którą się zamienia, w kluczu podstawowym). Po prostu sensowne jest, aby nie mieć niektórych przypadków, w których dane są nazywane liczbą mnogą, a niektóre są pojedynczymi.

Podsumowując, jeśli pluralizujesz nazwy swoich tabel, tracisz wiele korzyści, czyniąc kod inteligentniejszym i łatwiejszym w obsłudze. Mogą istnieć nawet przypadki, w których trzeba mieć tabele / tablice odnośników, aby przekonwertować nazwy tabel na obiekty lub lokalne nazwy kodowe, których można było uniknąć. Nazwy pojedynczych tabel, choć początkowo mogą wydawać się trochę dziwne, oferują znaczną przewagę nad mnogimi nazwami i uważam, że są najlepszą praktyką.

nasze preferencje:

1. Czy nazwy tabel powinny być w liczbie mnogiej?
   Nigdy. Argumenty przemawiające za tym, że jest to kolekcja, mają sens, ale nigdy nie wiadomo, co zawiera tabela (0,1 lub wiele pozycji). Liczba mnoga sprawia, że ​​nazewnictwo jest niepotrzebnie skomplikowane. 1 dom, 2 domy, mysz kontra mysz, osoba kontra ludzie, a my nawet nie spojrzeliśmy na żadne inne języki.

   Update person set property = 'value'działa na każdą osobę w tabeli.
   Select * from person where person.name = 'Greg'zwraca kolekcję / zestaw wierszy osoby wierszy.

2. Czy nazwy kolumn powinny być pojedyncze?
   Zwykle tak, z wyjątkiem przypadków łamania zasad normalizacji.

3. Czy powinienem prefiksować tabele lub kolumny?
   Głównie preferencje platformy. Wolimy poprzedzać kolumny nazwą tabeli. Nie prefiksujemy tabel, ale wykonujemy widoki prefiksów (v_) i procedury przechowywane_procedury (sp_ lub f_ (funkcja)). Pomaga to osobom, które chcą spróbować zaktualizować v_person.age, który jest polem obliczonym w widoku (którego i tak nie można zaktualizować).

   Jest to również świetny sposób na uniknięcie kolizji słów kluczowych (delivery.from zepsuje, ale delivery_from nie).

   To sprawia, że ​​kod jest bardziej szczegółowy, ale często pomaga w czytelności.

   bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
   ... jest bardzo czytelny i wyraźny. Może to jednak wymknąć się spod kontroli:

   customer.customer_customer_type_id

   wskazuje relację między klientem a tabelą typu klient, wskazuje klucz podstawowy w tabeli typu klient (identyfikator_typu klienta), a jeśli kiedykolwiek zobaczysz „identyfikator_typu klienta” podczas debugowania zapytania, od razu wiesz, skąd pochodzi (tabela klientów).

   lub w przypadku relacji MM między typem klienta a kategorią klienta (tylko niektóre typy są dostępne dla niektórych kategorii)

   customer_category_customer_type_id

   ... jest trochę (!) długa strona.

4. Czy powinienem używać nazwy w nazwach przedmiotów? Tak - małe litery :), z podkreśleniami. Są to bardzo czytelne i wieloplatformowe. W połączeniu z 3 powyżej ma to również sens.

   Większość z nich to jednak preferencje. - O ile jesteś konsekwentny, powinno być przewidywalne dla każdego, kto musi to przeczytać.

Spójrz na ISO 11179-5: Zasady nazewnictwa i identyfikacji Możesz go uzyskać tutaj: http://metadata-standards.org/11179/#11179-5

Pisałem o tym na blogu jakiś czas temu: Konwencje nazewnictwa ISO-11179

Wiem, że jest już za późno na grę i odpowiedź na to pytanie jest już bardzo dobra, ale chcę wyrazić swoją opinię na temat # 3 dotyczącego prefiksu nazw kolumn.

Wszystkie kolumny należy nazwać prefiksem unikalnym dla tabeli, w której są zdefiniowane.

Np. Biorąc pod uwagę tabele „klient” i „adres”, przejdźmy do prefiksów odpowiednio „cust” i „addr”. „klient” zawiera „cust_id”, „cust_name” itd. „adres” zawierałby „addr_id”, „addr_cust_id” (FK wraca do klienta), „addr_street” itp.

Kiedy po raz pierwszy przedstawiono mi ten standard, byłem przeciwny temu; Nienawidziłem tego pomysłu. Nie mogłem znieść myśli o tym dodatkowym pisaniu i redundancji. Teraz mam wystarczająco dużo doświadczenia, że ​​nigdy nie wrócę.

W wyniku tego wszystkie kolumny w schemacie bazy danych są unikalne. Jest to jedna główna korzyść, która przewyższa wszystkie argumenty przeciwko niemu (moim zdaniem oczywiście):

Możesz przeszukać całą bazę kodu i niezawodnie znaleźć każdy wiersz kodu, który dotyka określonej kolumny.

Korzyści z # 1 są niewiarygodnie ogromne. Mogę wycofać kolumnę i dokładnie wiedzieć, jakie pliki należy zaktualizować, zanim kolumna będzie mogła zostać bezpiecznie usunięta ze schematu. Mogę zmienić znaczenie kolumny i dokładnie wiedzieć, jaki kod należy refaktoryzować. Mogę też po prostu stwierdzić, czy dane z kolumny są nawet używane w określonej części systemu. Nie mogę policzyć, ile razy zamienił potencjalnie ogromny projekt w prosty, ani ile godzin zaoszczędziliśmy na pracach programistycznych.

Inną, stosunkowo niewielką korzyścią jest to, że musisz używać aliasów tabeli tylko podczas samodzielnego łączenia:

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%';

Moje opinie na ich temat są następujące:

1) Nie, nazwy tabel powinny być pojedyncze.

Choć wydaje się, że prosty wybór ( select * from Orders) ma sens, ma mniej sensu dla ekwiwalentu OO ( Orders x = new Orders).

Tabela w DB jest tak naprawdę zbiorem tego bytu, ma to większy sens, gdy używasz logiki set:

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

Ta ostatnia linia, rzeczywista logika łączenia, wydaje się myląca z mnogimi nazwami tabel.

Nie jestem pewien, czy zawsze użyję aliasu (jak sugeruje Matt), aby to wyjaśnić.

2) Powinny być pojedyncze, ponieważ posiadają tylko 1 własność

3) Nigdy, jeśli nazwa kolumny jest niejednoznaczna (jak wyżej, gdzie oba mają kolumnę o nazwie [Klucz]), nazwa tabeli (lub jej alias) może je wystarczająco rozróżnić. Chcesz, aby zapytania były szybkie i proste - prefiksy dodają niepotrzebnej złożoności.

4) Cokolwiek chcesz, sugeruję CapitalCase

Nie sądzę, aby istniał jeden zestaw bezwzględnych wytycznych dotyczących któregokolwiek z nich.

Tak długo, jak cokolwiek wybierzesz, jest spójne w całej aplikacji lub DB, nie sądzę, że to naprawdę ma znaczenie.

W mojej opinii:

1. Nazwy tabel powinny być w liczbie mnogiej.
2. Nazwy kolumn powinny być pojedyncze.
3. Nie.
4. CamelCase (mój preferowany) lub podkreślenie_separowane zarówno dla nazw tabel, jak i nazw kolumn.

Jednak, jak wspomniano, każda konwencja jest lepsza niż żadna konwencja. Bez względu na to, jak to zrobisz, udokumentuj to, aby przyszłe modyfikacje były zgodne z tymi samymi konwencjami.

Myślę, że najlepsza odpowiedź na każde z tych pytań zostanie udzielona przez ciebie i twój zespół. O wiele ważniejsze jest, aby mieć konwencję nazewnictwa niż jej dokładna konwencja.

Ponieważ nie ma właściwej odpowiedzi na to pytanie, powinieneś poświęcić trochę czasu (ale nie za dużo) i wybrać własne konwencje oraz - oto ważna część - trzymać się tego.

Oczywiście dobrze jest poszukać informacji na temat standardów w tym zakresie, o co pytasz, ale nie martw się ani nie martw o liczbę różnych odpowiedzi, które możesz uzyskać: wybierz tę, która wydaje Ci się lepsza.

Na wszelki wypadek oto moje odpowiedzi:

1. Tak. Stół to grupa akt , nauczycieli lub aktorów , więc ... liczba mnoga.
2. Tak.
3. Nie używam ich.
4. Baza danych, z której korzystam częściej - Firebird - przechowuje wszystko dużymi literami, więc to nie ma znaczenia. W każdym razie, kiedy programuję, piszę nazwy w sposób łatwiejszy do odczytania, na przykład releaseYear .

1. Zdecydowanie utrzymuj nazwy tabel w liczbie pojedynczej, osoba nie ludzie
   2. To samo tutaj
   3. Nie. Widziałem kilka strasznych prefiksów, które posunęły się do stwierdzenia, że ​​to, z czym mieliśmy do czynienia, to tabela (tbl_) lub procedura sklepu użytkownika (usp_). Następnie nazwa bazy danych ... Nie rób tego!
   4. Tak. Mam tendencję do PascalCase wszystkich moich nazw tabel

Konwencje nazewnictwa pozwalają zespołowi programistycznemu zaprojektować wykrywalność i łatwość konserwacji w centrum projektu.

Dobra konwencja nazewnictwa wymaga czasu, aby ewoluować, ale po jej wprowadzeniu pozwala zespołowi posuwać się naprzód za pomocą wspólnego języka. Dobra konwencja nazewnictwa rośnie wraz z projektem. Dobra konwencja nazewnictwa łatwo radzi sobie ze zmianami podczas najdłuższej i najważniejszej fazy cyklu życia oprogramowania - zarządzania usługami w produkcji.

Oto moje odpowiedzi:

1. Tak, nazwy tabel powinny być w liczbie mnogiej, gdy odnoszą się na przykład do transakcji , papierów wartościowych lub kontrahentów .
2. Tak.
3. Tak. Tabele SQL mają prefiks tb_, widoki mają prefiks vw_, procedury składowane mają prefiks usp_, a wyzwalacze są poprzedzone tg_, a następnie nazwą bazy danych.
4. Nazwa kolumny powinna być pisana małymi literami, oddzielona znakiem podkreślenia.

Nazewnictwo jest trudne, ale w każdej organizacji jest ktoś, kto potrafi nazwać różne rzeczy, aw każdym zespole oprogramowania powinien być ktoś, kto bierze odpowiedzialność za standardy nazewnictwa i zapewnia, że ​​problemy z nazewnictwem, takie jak sec_id , sec_value i security_id, zostaną rozwiązane wcześniej, zanim zostaną upieczone w projekcie .

Jakie są więc podstawowe zasady dobrej konwencji nazewnictwa i standardów:

• Użyj języka swojego klienta i domeny rozwiązania
• Bądź opisowy
• Bądź konsekwentny
• Ujednoznacznij, zastanów się i refaktoryzuj
• Nie używaj skrótów, chyba że są one jasne dla wszystkich
• Nie używaj zastrzeżonych słów kluczowych SQL jako nazw kolumn

Oto link, który oferuje kilka opcji. Szukałem prostej specyfikacji, którą mogłem zastosować, zamiast polegać na częściowo zdefiniowanej.

http://justinsomnia.org/writings/naming_conventions.html

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

Nazwy tabel powinny zawsze być pojedyncze, ponieważ reprezentują zestaw obiektów. Jak mówisz, stado wyznacza grupę owiec lub stado wyznacza grupę ptaków. Nie ma potrzeby liczby mnogiej. Kiedy nazwa tabeli składa się z dwóch nazw, a konwencja nazewnictwa jest w liczbie mnogiej, trudno jest ustalić, czy nazwa w liczbie mnogiej powinna być pierwszym słowem, czy drugim słowem, czy jednym i drugim. To logika - Object.instance, a nie objects.instance. Lub TableName.column, a nie TableNames.column (s). Microsoft SQL nie rozróżnia wielkości liter, łatwiej jest odczytywać nazwy tabel, jeśli używa się wielkich liter, aby oddzielić nazwy tabel lub kolumn, gdy składają się z dwóch lub więcej nazw.

Nazwa tabeli: Powinna być pojedyncza, ponieważ jest pojedynczą jednostką reprezentującą obiekt świata rzeczywistego, a nie obiekty, które są osobliwe.

Nazwa kolumny: powinna być pojedyncza tylko wtedy, gdy będzie zawierać wartość atomową i potwierdzi teorię normalizacji. Jeśli jednak istnieje n liczby tego samego typu właściwości, należy je dodać 1, 2, ..., n itd.

Tabele prefiksów / kolumny: To ogromny temat, który omówimy później.

Obudowa: Powinna to być obudowa Camel

Mój przyjaciel, Patrick Karcher , proszę, abyś nie pisał niczego, co mogłoby być obraźliwe dla kogoś, jak napisałeś: „• Ponadto, klucze obce muszą być konsekwentnie wymieniane w różnych tabelach. Pobicie kogoś, kto nie jest legalny, powinno być legalne Zrób to.". Nigdy nie popełniłem tego błędu, mój przyjaciel Patrick, ale piszę ogólnie. Co jeśli razem planują cię za to pokonać? :)

Bardzo późno na imprezę, ale nadal chciałem dodać dwa centy za prefiksy kolumn

Wydaje się, że istnieją dwa główne argumenty za użyciem standardu nazewnictwa table_column (lub tableColumn) dla kolumn, oba w oparciu o fakt, że sama nazwa kolumny będzie unikalna w całej bazie danych:

1) Nie musisz przez cały czas podawać nazw tabel i / lub aliasów kolumn w swoich zapytaniach

2) Możesz łatwo przeszukać cały kod w poszukiwaniu nazwy kolumny

Myślę, że oba argumenty są błędne. Rozwiązanie obu problemów bez użycia prefiksów jest łatwe. Oto moja propozycja:

Zawsze używaj nazwy tabeli w swoim SQL. Np. Zawsze używaj table.column zamiast column.

Oczywiście rozwiązuje 2), ponieważ teraz możesz po prostu wyszukać table.column zamiast table_column.

Ale słyszę twój krzyk, jak to rozwiązuje 1)? Chodziło właśnie o to, aby tego uniknąć. Tak, ale rozwiązanie było okropnie wadliwe. Dlaczego? Cóż, rozwiązanie przedrostka sprowadza się do:
Aby uniknąć konieczności określania table.column, gdy występuje niejednoznaczność, nazwij wszystkie kolumny table_column!
Ale oznacza to, że odtąd będziesz ZAWSZE musiał pisać nazwę kolumny za każdym razem, gdy określisz kolumnę. Ale jeśli i tak musisz to zrobić, jaka jest korzyść w stosunku do zawsze jawnego pisania table.column? Dokładnie, nie ma korzyści, jest to dokładnie taka sama liczba znaków do wpisania.

edycja: tak, wiem, że nazewnictwo kolumn prefiksem wymusza prawidłowe użycie, podczas gdy moje podejście zależy od programistów

Niezbędne konwencje nazewnictwa baz danych (i styl) (kliknij tutaj, aby uzyskać bardziej szczegółowy opis)

nazwy tabel wybierają krótkie, jednoznaczne nazwy, używając nie więcej niż jednego lub dwóch słów rozróżnij tabele z łatwością ułatwia nazywanie unikalnych nazw pól, a tabele wyszukiwania i łączenia dają tabelom nazwy pojedyncze, nigdy w liczbie mnogiej (aktualizacja: nadal zgadzam się z podanymi przyczynami dla tej konwencji, ale większość ludzi naprawdę lubi nazwy w liczbie mnogiej, więc złagodziłem swoją postawę) ... proszę skorzystać z powyższego linku

Nazwy tabel w liczbie pojedynczej. Powiedzmy, że modelujesz relacje między kimś a jego adresem. Na przykład, jeśli czytasz model danych, wolałbyś „każda osoba może mieszkać pod adresem 0,1 lub wieloma”. lub „każdy naród może mieszkać pod 0,1 lub wieloma adresami”. Wydaje mi się, że łatwiej jest podać liczbę adresową w postaci liczby mnogiej niż wymieniać osoby jako osoby. Plus rzeczowniki zbiorowe są dość często odmienne od pojedynczej wersji.

--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
);

Nauczono mnie takich konwencji, ale powinieneś dostosować się do wszystkiego, czego używasz węża.

1. Liczba mnoga. Jest to zbiór bytów.
2. Tak. Atrybut jest reprezentacją pojedynczej właściwości bytu.
3. Tak, nazwa tabeli prefiksu pozwala na łatwe śledzenie nazw wszystkich indeksów ograniczeń i aliasów tabeli.
4. Wielkość liter Pascala dla nazw tabel i kolumn, prefiks + WSZYSTKIE wielkie litery dla indeksów i ograniczeń.