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

790

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?

GateKiller
źródło
7
Myślę, że powinniśmy nazwać liczbę mnogą dla tabel i liczbę pojedynczą dla kolumn.
AZ_
7
Widzę tabelę jako „pamięć” z wieloma elementami, a nie pojedynczą „jednostką”, więc nazywam ją liczbą mnogą. Kiedy mapowałem tabele na obiekty, nazwałbym je pojedynczymi. To tylko moja osobista opinia.
dpp
2
@Tryinko Używanie identyfikatora w każdym miejscu jest ŻYWYM PIEKŁEM dla każdego, kto wykonuje łączenia wielu stołów. Nie ma żadnej możliwości, aby niewielka zaleta wynikająca ze znajomości PK przeważyła niewiarygodną irytację polegającą na ponownym aliasingu kolumny identyfikatora Dang w każdym krwawym zapytaniu w kółko. Jeśli chcesz sposób na oznaczenie PK w tabeli, ustaw ją jako pierwszą kolumnę. Również oznaczanie FK w nazwach kolumn jest moim zdaniem kolejnym całkowicie złym anty-wzorem.
ErikE
2
Spójrz na tę odpowiedź .
PerformanceDBA,

Odpowiedzi:

315

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)
urini
źródło
14
wilsonmar.com/sql_adventureworks.htm to doskonała analiza schematu AdventureWorks.
Daniel Trebbien
209
Nie polegałbym na Microsoft w przypadku żadnego standardu - jeśli spojrzysz na ich bazę danych Northwind, zobaczysz, że używają tablic w liczbie mnogiej, pojedynczych nazw kolumn, prefiksów schematów dla tabel, prefiksów tabel dla kolumn klucza podstawowego, węgierskich prefiksów ograniczeń i najgorszych wszystkich SPACES „” dla nazw tabel zawierających wiele słów. Dodatkowo tabele systemowe dla SQLServer używają liczby mnogiej, więc wydaje się, że AdventureWorks była czarną owcą w tej grupie.
Marcus Pope
63
Myślę, że głównym problemem jest to, że tłum nazw pojedynczych tabel wydaje się uważać tabelę za byt, a nie wiersz w tabeli, który robi tłum mnogi. Musisz zapytać siebie, która to jest. Jeśli tabela jest tylko kontenerem wierszy, czy nie jest bardziej logiczne stosowanie liczby mnogiej? Nigdy nie nazwałbyś kolekcji pojedynczym kodem, więc dlaczego nazwałbyś tabelę pojedynczą? Dlaczego niespójność? Słyszę wszystkie argumenty o tym, jak sortują i używają w złączeniach, ale wszystkie te wydają się bardzo wątłe. Jeśli wszystko sprowadza się do preferencji, pójdę z konsekwencją i pluralizuję.
Jason
4
Zastanów się także, w którą stronę płynie fala. Wygląda na to, że zmierza w kierunku nazw tabel w liczbie mnogiej, zwłaszcza że wszystkie tabele systemowe w SQL Server są w liczbie mnogiej, a domyślne ustawienie dla Entity Framework jest w liczbie mnogiej po wyjęciu z pudełka. Jeśli takie jest stanowisko Microsoftu, chcę iść w kierunku, w którym będziemy za 20 lat. Nawet konwencje bazy danych Oracle zawierają nazwy w liczbie mnogiej. Pomyśl tylko, ilu programistów c # nienawidziło słowa kluczowego „var”, kiedy zostało ono wprowadzone, teraz jest to powszechnie akceptowany sposób definiowania zmiennych.
Jason
7
@Jasmine - Widzę twój punkt widzenia, choć myślę, że przypadkowo nazwałeś swoją przykładową tabelę odwróconą. „TableOfInvoices” należy skrócić do „Faktur”, co wolę. Prawdopodobnie miałeś na myśli „InvoiceTable”, co ma sens, aby skrócić „Fakturę”.
Derek
279

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.
Patrick Karcher
źródło
11
„Pola reprezentujące ten sam rodzaj danych w różnych tabelach powinny mieć takie same nazwy. Nie używaj Zip w jednej tabeli, a ZipCode w drugiej.” Tak tak milion razy tak. Czy możesz powiedzieć, że nasza baza danych nie została zaprojektowana w ten sposób? Personid może być przywołany na każdy z kilkunastu różnych sposobów, bardzo denerwujących w utrzymaniu. Zawsze trzymałem się tej zasady w każdej bazie danych, którą miałem kontrolę nad projektowaniem, a to znacznie ułatwia życie.
HLGEM
87
Myślę, że kluczem podstawowym powinno być po prostu „ID”. Taka prosta konwencja sprawia, że ​​klucz podstawowy jest przewidywalny i szybko identyfikowalny. Dodałbym jednak nazwę tabeli („PersonID”), gdy jest ona używana jako klucz obcy w innych tabelach. Ta konwencja może pomóc w odróżnieniu klucza podstawowego od kluczy obcych w tej samej tabeli.
Triynko
55
@Tryinko Używanie identyfikatora w każdym miejscu jest ŻYWYM PIEKŁEM dla każdego, kto wykonuje łączenia wielu stołów. Nie ma żadnej możliwości, aby niewielka zaleta wynikająca ze znajomości PK przeważyła niewiarygodną irytację polegającą na ponownym aliasingu kolumny identyfikatora Dang w każdym krwawym zapytaniu w kółko. Jeśli chcesz sposób na oznaczenie PK w tabeli, ustaw ją jako pierwszą kolumnę. Również oznaczanie FK w nazwach kolumn jest moim zdaniem kolejnym całkowicie złym anty-wzorem.
ErikE
18
@Triynko, jeśli użyjesz tylko „ID”, ustalenie tabeli, do której należy, staje się również programowo niemożliwe. Za pomocą prefiksu nazwy tabeli możesz po prostu odciąć dwie ostatnie cyfry klucza podstawowego i poznać nazwę tabeli, do której należy, za pomocą kodu. Często informatycy i DBA nie zdają sobie sprawy z tego, że programiści mają pewne zalety programistyczne przy projektowaniu baz danych w określony sposób.
dallin
16
@ErikE Mam na myśli, że nie wiesz, czy CustomerIDjest to klucz podstawowy z Customertabeli, czy klucz obcy w innej tabeli. To drobny problem. Dlaczego chcesz używać takich złych nazwisk jak c? CustomerID = Customer.IDjest bardzo jasne, ponieważ widzisz, że łączysz klucz obcy z kluczem podstawowym; nie jest zbędny, ponieważ dwie strony to dwie różne rzeczy. Nazewnictwo pojedynczymi znakami to zła praktyka IMO.
Dave Cousineau
100

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.

Matt Hamilton
źródło
17
@Emtucifor: Po angielsku nie mówimy „Spójrz na całą osobę w tym tłumie!” Należy się spodziewać pojęciowego problemu z wieloma rzeczami, do których odnosi się pojedyncze słowo. To nie jest ani zwykłe, ani właściwe. „Dane” są wyjątkowe i często używane w odniesieniu do kawałka substancji, podobnie jak „ciasto”. "Czy chciałbyś kawałek ciasta?" Nazywanie tabeli „Ludzie”, ponieważ zawiera informacje o wielu osobach, ma o wiele większy sens niż nazywanie jej „Osoba”. Sensowna jest klasa danych o nazwie „Osoba” dla ROW, podobnie jak pojedyncze nazwy kolumn.
Triynko,
6
@Emtucifor: Ostatecznie cały język jest arbitralny i konwencjonalny. Właśnie argumentowałem, że umownie nazywamy zbiór przedmiotów liczbą mnogą tego rodzaju przedmiotów. Tak więc zbiór wierszy, w których każdy wiersz zawiera informacje o jednej osobie, byłby określany jako zbiór Ludzi. Ale jeśli chcesz nazywać to kolekcją Osoby, śmiało.
Triynko
3
@Emtucifor: Tak, lol. Nazwanie tabeli „PersonCollection” byłoby równoznaczne z nazwaniem jej „People”. Porównajmy to z nazwaniem takiej kolekcji po prostu „Osoba”, co nie ma sensu :)
Triynko
4
@Emtucifor: Pomyślmy o tym z innej perspektywy, aby umieścić konwencję nazewnictwa w kontekście. Załóżmy, że masz klasy obiektów reprezentujące zarówno wiersz, jak i tabelę. „Osoba” ma oczywiście sens w przypadku klasy reprezentującej wiersz danych. Jeśli twoja tabela została również nazwana „Osoba”, możesz mieć konflikt nazw lub zamieszanie. Po prostu uważam, że bardziej sensowne jest nazywanie obiektów z dokładną mnogością. Wiersz z danymi o osobie powinien nosić nazwę Osoba, a tabela z informacjami o osobach lub wielu osobach nosi nazwę Ludzie, PersonCollection, Osoby itp.
Triynko
5
@Josh M. Cóż, nie w obie strony. Jeśli pójdziesz moją drogą, możesz aliasować tabelę People jako „person” i mieć SELECT person.Name. Problem rozwiązany. ;-)
Matt Hamilton
73

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.

Chłopak
źródło
9
Zwłaszcza w przypadku numeru 3 mieliśmy grupę ludzi, którzy zostali zatrudnieni w tej samej firmie i próbowali narzucić swój stary standard nazewnictwa (którego nikt z nas nie używał) na cokolwiek, co zrobili. Bardzo irytujące.
HLGEM
40
Z pewnością sprawia, że ​​SQL jest nieczytelny; ale myślę, że potrafię tłumaczyć. cust_nm powinno być CustomerName , booking_dt powinno być BookingDate . reg_customer, cóż, nie mam pojęcia co to jest.
Ian Boyd
3
@Ian. Chodzi o to, abyś trzymał się konwoju nazewnictwa, do którego byłeś przyzwyczajony, i byś był spójny. ZAWSZE wiem, że każde pole daty to _dt, każde pole nazwy to _nm. „reg” jest przykładem systemu „rejestracji” (rezerwacje, klienci itp.), a wszystkie powiązane tabele miałyby ten sam prefiks. Ale każdy do siebie ...
Guy
7
Zgadzam się, że określony standard nie jest tak ważny jak posiadanie spójnego standardu. Ale niektóre standardy są błędne. Nazwy DB2 i kolumn, takie jak CSPTCN, CSPTLN, CSPTMN, CSDLN. Ludzie powinni dowiedzieć się, że wymyślono długie nazwiska - możemy sobie pozwolić na uczynienie rzeczy czytelnymi.
Ian Boyd
17
Z biegiem lat dodawałem nowe kolumny na końcu moich tabel w aplikacji, którą opracowałem i sprzedałem. Czasami używam angielskich nazw w moich kolumnach, czasami używam hiszpańskiego, a czasem ponownie używam kolumn do czegoś innego, zamiast ich usuwania i dodawania nowej kolumny z odpowiednią nazwą opisową dla tego, co jest używane. Celowo zrobiłem to, aby OBFUSCATE mój kod źródłowy na wypadek, gdyby ktoś próbował zhakować lub poddać inżynierii wstecznej mój kod. Tylko ja to rozumiem, ktoś się sfrustruje! .. W ten sposób zawsze muszą na mnie polegać!
Frank R.
47
  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 $

Lars Mæhlum
źródło
5
Dodanie pewnej przejrzystości do numeru 3 - prefiksy są sposobem na osadzenie metadanych w nazwie kolumny. Nie powinno być takiej potrzeby w żadnym nowoczesnym DB z tych samych powodów, co (nadużycie) notacji węgierskiej.
Mark McDonald
21
„wybierz 15 najlepszych z zamówienia” czy „wybierz 15 najlepszych z zamówień”? To ostatnie jest moją (ludzką) preferencją.
Ian Boyd
8
@Ian Boyd: Tak: WYBIERZ TOP 100 * Z raportu R DOŁĄCZ DO WEWNĘTRZ VisitReport VR ON R.ReportID = VR.ReportID. Wszystko zależy od tego, jak o tym myślisz. Jeśli umieścisz zdjęcie cytryny na pojemniku, będziesz wiedział, że w środku są cytryny, bez potrzeby używania dwóch cytryn na zewnątrz, aby wskazać, że może być w liczbie mnogiej. Jasne, możesz nazwać to słowem „cytryny”. Ale równie dobrze może to być „cytryna”. Aby zdobyć zasób o nazwie „cytryna”, przejdź tutaj.
ErikE
6
dodaj 0,01 USD za użycie UpperCase w nazwach kolumn i dodaj kolejne 0,01 USD za użycie podkreślenia w nazwach kolumn, aby łatwiej było odróżnić nazwy kolumn na widoku. Łącznie = moja darowizna w wysokości 0,02 USD!
Frank R.
6
„Tabelę należy nazwać po encji, którą reprezentuje”. Tabela to zbiór encji. Chociaż tabela jest również bytem, ​​jest to byt typu „Tabela”, którego dodawanie do nazwy nie ma sensu.
Trisped
34

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

oneedaywhen
źródło
-1: Przywoływany tekst nie ma nic wspólnego z ISO / IEC 11179. Przywoływanej stronie wikipedii nie należy ufać; zamiast tego przeczytaj aktualny standard ( metadata-standards.org/11179/#A5 )
mkadunc
@onedaywhen: Nie wiem wystarczająco dużo na ten temat, aby poprawić stronę Wikipedii; Ponadto strona wikipedia nie jest tak bardzo błędna, jak wprowadzająca w błąd - nie mówi wprost, że ISO / IEC 11179 obejmuje konwencje nazewnictwa baz danych, po prostu mówi, że „ISO / IEC 11179 ma zastosowanie przy nazywaniu tabel i kolumn w relacyjna baza danych ”. Następnie podaje przykład konwencji nazewnictwa, które można zastosować w relacyjnej bazie danych. Pozwala ci myśleć, że przykład jest czymś wziętym ze standardu, a tak naprawdę jest to coś, co wymyślił autor artykułu z Wikipedii.
mkadunc
27

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

Dallin
źródło
26

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

Albert
źródło
1
SELECT * FROM people AS person WHERE person.name = 'Greg'brzmi dla mnie najbardziej naturalnie.
Kenmore
1
@Zuko Głównie konwencja nazewnictwa tabeli klucza podstawowego jest <table name><id>, na przykład PersonIDczy Person_IDitd Dlatego większy sens, że nie imię i nazwisko Twój tabel w liczbie mnogiej, jak każdy rekord jest odrębną osobą nie ludzie.
Pan Blond
15

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%';
Granger
źródło
1
Więc nie możesz już reliably find every line of code that touches a particular column... Czy nie o to chodzi?
raveren
6
@Raveren - Nadal możesz. Jeśli wszystko, co robisz, to „WYBIERZ *”, wówczas zapytanie nie ma znaczenia w tym celu. Kiedy / jeśli później użyjesz wyników tego zapytania, musisz użyć nazwy kolumny, aby zrobić coś z jej danymi, więc jest to miejsce, o które musisz się martwić w swoim kodzie, a nie w instrukcji SQL.
Granger,
Chciałbym być ciekawy, jakie sytuacje wymagają WYBIERZ *? Z pewnością nie chciałbym, aby ktokolwiek używał tego w kodzie produkcyjnym. Tak, jest to przydatne w przypadku zapytań ad hoc i ustalenia, który fragment danych powoduje, że wyniki wielu zapytań łączących są nieparzyste, ale nie mogę wymyślić żadnego miejsca w kodzie produkcyjnym, w którym byłoby to wymagane.
HLGEM,
2
O ile nie kodujesz całej aplikacji w języku innym niż język OO, to posiadanie przyzwoitej warstwy ORM powoduje, że ten argument jest zbędny.
Adam
6
W związku z tą odpowiedzią postanowiłem spróbować użyć prefiksów tabel w dużym projekcie i pomyślałem, że mogę to zgłosić. Dzięki temu refaktoryzacja stołów była wyjątkowo łatwa, co było niesamowite! Był to jednak większy ból, niż się spodziewałem. Nasza baza danych zawierała wiele złożonych nazwanych tabel. Łatwo zapamiętać Cust jest prefiksem dla Klienta, ale nie tak łatwo zapamiętać prefiks dla HazardVerificationMethod. Za każdym razem, gdy pisałem tabelę lub pole, musiałem się zatrzymać, aby pomyśleć o prefiksie. W końcu zdecydowałem, że szybkość i wygoda są ważniejsze niż możliwość wyszukiwania, ale czułem, że było to cenne doświadczenie.
dallin
15

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.

Keith
źródło
3
Co do cholery jest CapitalCase?
ViRuSTriNiTy
@ViRuSTriNiTy prawdopodobnie miał na myślipascal case
2017
Keith, pod numerem 3 robię oba i jestem niespójny (ale dygresję), ale nie rozumiem, dlaczego źle jest mieć opisową nazwę kolumny, o ile nie jest ona za burtą, podobnie jak w tabeli, zmienna itp.
John
@ Johnny nie jest źle, jako takie, po prostu nie potrzebne. Po co pisać rzeczy, których nie musisz? Również większość intellisense głównie wykorzystuje początek nazwy, więc jeśli masz Product.ProductName, Product.ProductID, Product.ProductPriceetc typowania Product.Pdaje wszystkie prefiksem pól.
Keith
13

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.

Thomas Owens
źródło
1
odnośnie # 4, PascalCase ... camelCase ... snake_case ...
Andrew
11

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 .
Mario Marinato
źródło
11
  1. Zdecydowanie utrzymuj nazwy tabel w liczbie pojedynczej, osoba nie ludzie
    1. To samo tutaj
    2. 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!
    3. Tak. Mam tendencję do PascalCase wszystkich moich nazw tabel
dzwon
źródło
28
O MÓJ BOŻE. NIE. Nazwy tabel ZDEFINIOWANE w liczbie mnogiej. To KOLEKCJA. Zawiera wiele rzeczy. „wybierz * z LUDZI”. Nie wybierasz jednej osoby, wybierasz spośród wielu LUDZI!
Triynko,
4
Zawsze lubiłem sposób, w jaki instrukcja select brzmi lepiej, jeśli jest w liczbie mnogiej. SELECT id,name FROM contacts WHERE email_address LIKE '%gmail%'tabele w liczbie mnogiej, kolumny w liczbie pojedynczej. Znowu zawsze jest to kwestia osobistej opinii.
scunliffe
prefiksowanie tbl, qry itp. może być bardzo przydatne podczas obsługi metadanych bazy danych. Jeśli badasz obiekt w bazie danych, posiadanie szybkiej, prostej konwencji nazewnictwa może znacznie przyspieszyć rozumienie
Cruachan
9

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
winsql
źródło
3
tabele są z definicji relacjami. które w rzeczywistości są pojedyncze. Przedrostki są do kitu. Czy kiedykolwiek potrzebowałeś zmienić tabelę w widok lub odwrotnie? spróbuj tego z prefiksami. jaką to robi różnicę, jeśli jest to widok lub stół?
William Jones,
Prefiks może pomóc, gdy mamy taką samą nazwę dla dwóch obiektów - takich jak funkcja i procedura przechowywana. Chciałbym mieć funkcję o nazwie „GetApproverList” i o tej samej nazwie chciałbym utworzyć procedurę składowaną, która wywoła tę funkcję wewnętrznie. Sql nie pozwoli na utworzenie dwóch obiektów o tej samej nazwie.
Ravinder Singh,
7
SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName
Ian Boyd
źródło
2
Zwróć uwagę na zastosowane standardy: tabele zawierają wiele rzeczy, użytkownicy mają jedno imię, słowa kluczowe T-SQL pisane wielkimi literami, definicje tabel w przypadku Pascala.
Ian Boyd
3
literówka: Lastnamepowinno byćLastName
aminimalanimal
1
Nazwa tabeli powinna być pojedyncza, tj .: Użytkownik zamiast Użytkownicy
AZ_
I zwróć uwagę na liczbę mnogą nazw tabel; ponieważ przechowują użytkowników , a nie użytkowników .
Ian Boyd
5

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.

Annie
źródło
2
Stado to grupa owiec . UserTo nie grupa użytkowników.
EricRobertBrewer
4

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ć? :)

Vishesh Marwah
źródło
2
Więc mówisz, że stół jest bytem? A może wiersz w tabeli jest bytem? Dla mnie tabela jest zbiorem wierszy - a więc zbiorem bytów, które implikują liczbę mnogą.
Jason
4

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

janb
źródło
1
Jak wspomniałeś, nie możesz polegać na każdym przypadku z tabelą.kolumna. Programiści zapomną w jednym miejscu, a wtedy twoje globalne wyszukiwanie i wymiana po prostu zepsuło cały twój program. Albo uczynisz to regułą, a ktoś pomyśli, że spełnia regułę, używając aliasu tabeli, tym samym ponownie udaremniając globalne znalezisko. Ponadto, jeśli chcesz uporządkować kod, mając jakąś klasę bazy danych (co zrobi każdy dobry programista), będą chwile, gdy po prostu przekażesz nazwę kolumny do funkcji db lub po prostu będziesz miał nazwę samej kolumny w zmienna.
dallin 29.04.13
2
@janb: Całkowicie popieram twoją odpowiedź. Chcę również dodać, że wyszukiwanie tekstu w celu znalezienia zależności jest barbarzyńskim sposobem poruszania się po kodzie. Gdy ludzie pozbędą się tej barbarzyńskiej praktyki poszukiwania - zaczną używać dobrego nazywania, którym jest table.column. Problemem nie jest styl nazewnictwa, problemem są złe narzędzia stworzone dla barbarzyńców.
alpav
Twój argument jest błędny. Problem polega na tym, że działa on w obie strony i nie daje żadnych korzyści. Mówisz, aby rozwiązać ten problem, po prostu zawsze pisz table.column, ponieważ już piszesz table_column. Możesz też powiedzieć po prostu napisz kolumnę_tabeli, ponieważ już piszesz table.column. Innymi słowy, nie ma różnicy między twoją odpowiedzią, ale wprowadza ona ewentualne błędy i nie wymusza konwencji. To jest powód, dla którego mamy „prywatne” słowo kluczowe. Możemy zaufać programistom, że zawsze będą poprawnie używać zmiennych klas, ale słowo kluczowe wymusza je i eliminuje ewentualne błędy.
dallin
3

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

AZ_
źródło
1
chociaż to, co Oracle sugeruje, jest zupełnie przeciwne do link linke powyżej. dowiedz się, co Oracle mówi tutaj .. ss64.com/ora/syntax-naming.html
AZ_
Konwencja nazewnictwa Oracle była najśmieszniejsza ze wszystkich .. e.g. PATIENTS would have a primary key called pa_patient_id_pk!!
nawfal
2

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.

paul444
źródło
-4

--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ń.
Lord Future
źródło
6
ChristianName ... to dziwna konwencja.
BobbyShaftoe
3
Numery seryjne na twoich stołach? Czy ktoś poważnie myśleć to sens dzieła dla deweloperów?
ErikE
Odkąd ten przykład go przywołał ... Osobiście sprzeciwiam się wprowadzaniu dużych skrótów w nazwach tabel lub kolumn, ponieważ myślę, że utrudnia to czytanie. Więc w tym przypadku powiedziałbym, że StudentId jest lepszy niż StudentID. Nie jest to wielka sprawa, gdy akronim jest na końcu, ale widziałem niezliczone przykłady w mojej pracy, w których akronimy znajdowały się z przodu lub na środku nazwy, i utrudniało to parsowanie w twoim umyśle. Np .: StudentABCSSN vs StudentAbcSsn.
redOctober13