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

Późna odpowiedź tutaj, ale w skrócie:

1. Moje preferencje to liczba mnoga
2. Tak
3. tabele: * zwykle * nie ma przedrostków jest najlepszy. Kolumny : Nie.
4. zarówno tabele, jak i kolumny: PascalCase.

Opracowanie:

(1) co musisz zrobić. jest bardzo niewiele rzeczy, które musisz robić w określony sposób, za każdym razem, ale jest ich kilka.

• Nazwij swoje klucze podstawowe używając format "[singularOfTableName]ID". Oznacza to, że niezależnie od tego, czy nazwa tabeli to Customer czy Customers, kluczem głównym powinien być CustomerID.
• dalej, klucze obce muszą być nazwane konsekwentnie w różnych tabelach. Bicie kogoś, kto tego nie robi, powinno być legalne. Chciałbym powiedzieć, że chociaż zdefiniowane ograniczenia klucza obcego są Często Ważne, spójne nazewnictwo klucza obcego to Zawsze Ważne
• You database musi mieć wewnętrzne konwencje . Chociaż w późniejszych sekcjach zobaczysz, że jestem bardzo elastyczny, wewnątrz nazewnictwo bazy danych musi być bardzo spójne . To, czy Twoja tabela dla klientów nazywa się Customers czy Customer jest mniej ważne niż to, że robisz to w ten sam sposób w tej samej bazie danych. I możesz rzucić monetą, aby określić, jak używać podkreślników, ale wtedy musisz używać ich w ten sam sposób . Jeśli tego nie zrobisz, jesteś zły. osoba, która powinna mieć niską samoocenę.

(2) Co powinieneś zrobić.

• pola reprezentujące ten sam rodzaj danych w różnych tabelach powinny być nazwane tak samo. Nie ma Zip na jednym stole i ZipCode na innym.
• aby oddzielić słowa w nazwach tabeli lub kolumn, użyj PascalCasing. Używanie camelcasingu nie byłoby z natury problematyczne, ale to nie jest konwencja i wyglądałoby zabawnie. Zwrócę uwagę za chwilę. (Nie można używać ALLCAPS jak w dawnych czasach. OBNOXIOUSTABLE.ANNOYING_COLUMN w DB2 było ok 20 lat temu, ale nie teraz.)
• nie skracaj sztucznie ani nie skracaj słów. Lepiej jest, aby nazwa była długa i jasna niż krótka i myląca. Ultrakrótkie nazwy to hołd z mroczniejszych, bardziej dzikich czasów. Cus_AddRef. Co to jest? Numer Adresata? Dodatkowy Zwrot Przez Klienta? Adres Niestandardowy?

(3) Co ty powinniśmy to rozważyć.

• naprawdę uważam, że powinieneś mieć nazwy liczby mnogiej dla tabel; niektórzy myślą o liczbie pojedynczej. Przeczytaj argumenty gdzie indziej. Nazwy kolumn powinny być jednak pojedyncze. Nawet jeśli używasz nazw tabel w liczbie mnogiej, tabele reprezentujące kombinacje innych tabel mogą znajdować się w liczbie pojedynczej. Na przykład, jeśli masz tabelę Promotions i Items, tabelą przedstawiającą przedmiot będący częścią promocji może być Promotions_Items, ale może również zgodnie z prawem być Promotion_Items myślę(odzwierciedlając relację jeden do wielu).
• używać konsekwentnie i DO OKREŚLONEGO CELU. Tylko ogólne nazwy tabel powinny być wystarczająco jasne z PascalCasing; nie trzeba podkreślenia, aby oddzielić słowa. Zapisz podkreślniki albo (a), aby wskazać tabelę asocjacyjną, albo (b) dla prefiksu, który będę adresować w następnym wypunktowaniu.
Prefiks nie jest ani dobry, ani zły. To zazwyczaj nie jest najlepsze. W Twoim pierwszym db lub dwóch, ja nie sugeruje stosowania prefiksów do ogólnego grupowania tematycznego tabel. Tabele nie pasują łatwo do kategorii, a znalezienie tabel może utrudnić znalezienie tabel. Dzięki doświadczeniu możesz zaplanować i zastosować schemat prefiksu, który robi więcej dobra niż szkody. Pracowałem kiedyś w db, gdzie tabele danych zaczynały się od tbl, tabele konfiguracji z ctbl, widoki z vew, proc 's sp, i udf' s fn i kilka innych., konsekwentnie stosowane więc wyszło ok. Tylko wtedy, gdy potrzebujesz prefiksów, masz naprawdę oddzielne rozwiązania, które z jakiegoś powodu znajdują się w tym samym db; prefiks może być bardzo pomocny w grupowaniu tabel. Prefiksowanie jest również dobre w sytuacjach specjalnych, takich jak tymczasowe tabele, które chcesz wyróżnić.
• bardzo rzadko (jeśli kiedykolwiek) chciałbyś do kolumn przedrostkowych.

Ok, skoro ważymy się z opinią:

Uważam, że nazwy tabel powinny być liczby mnogiej. Tabele są zbiorem (tabelą) encji. Każdy wiersz reprezentuje pojedynczy element, a tabela reprezentuje kolekcję. Tak więc nazwałbym tabelę osób jednostek ludzi (lub osób, co tylko zapragniesz).

Dla tych, którzy lubią widzieć pojedyncze "nazwy encji" w zapytaniach, do tego używałbym aliasów tabel:

SELECT person.Name
FROM People person

Trochę jak LINQ " od osoby w ludziach wybierz person.Name".

Pracuję w zespole obsługi baz danych z trzema bazami danych i 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 standard już istnieje, użyj go. Nie twórz kolejnego standardu ani nie buduj istniejących standardów.

Używamy nazw pojedynczych dla tabel. Tabele zwykle poprzedzone są nazwą systemu (lub jego akronimem). Jest to przydatne, jeśli system złożony, ponieważ można zmienić prefiks, aby grupować tabele razem logicznie (np. reg_customer, reg_booking i regadmin_limits).

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

Tj.

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

Podczas tworzenia nowego projektu, polecam napisać wszystkie preferowane nazwy encji, prefiksy i akronimy i dać ten dokument deweloperom. Następnie, gdy zdecydują się utworzyć nową tabelę, mogą odwoływać się do dokumentu, a nie "zgadywać", jak powinna się nazywać tabela i pola.

Nie. Tabela powinna być nazwana po encji, którą reprezentuje. Osoba, a nie osoby, to sposób, w jaki odnosisz się do kogokolwiek z zapisów. Znowu to samo. Kolumna FirstName naprawdę nie powinna być nazywana FirstNames. Wszystko zależy od tego, co chcesz reprezentować w kolumnie. Nie. Tak. Dla jasności. Jeśli potrzebujesz mieć kolumny typu "FirstName", obudowa ułatwi czytanie.

Ok. To mój $0.02

Jestem również za konwencją nazewnictwa stylów ISO/IEC 11179, zauważając, że są one raczej wytycznymi niż nakazami.

Zobacz Nazwa elementu danych w Wikipedii :

" tabele są kolekcjami encji i są zgodne z wytycznymi dotyczącymi nazewnictwa kolekcji. Najlepiej stosować nazwę zbiorczą: np., Kadry. Liczba mnoga jest również poprawna: pracownicy. Niepoprawne nazwy to: Employee, Tblemployee i EmployeeTable."

Jak zawsze istnieją wyjątki od reguł np. tabeli która zawsze ma dokładnie jeden wiersz może być lepsza z pojedynczą nazwą np. tabelą konfiguracyjną. A konsekwencja jest najważniejsza: sprawdź, czy sklep ma konwencję, a jeśli tak, postępuj zgodnie z nią; jeśli ci się to nie podoba, zrób biznesową sprawę, aby ją zmienić, a nie być samotnym strażnikiem.

Nasze preferencje:

1. Czy nazwy tabel powinny być liczby mnogiej?
   Nigdy. Argumenty przemawiające za tym, że jest to zbiór mają sens, ale nigdy nie wiadomo, co zawiera tabela (0,1 lub wiele pozycji). Zasady liczby mnogiej sprawiają, że nazewnictwo niepotrzebnie się komplikuje. 1 Dom, 2 domy, mysz kontra mysz, osoba kontra ludzie, a 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ę / wiersz osoby rzędy.

2. Czy nazwy kolumn powinny być pojedyncze?
   Zazwyczaj tak, z wyjątkiem przypadków, w których łamiesz zasady normalizacji.

3. Czy powinienem prefiksować tabele lub kolumny?
   Głównie preferencje platformy. Preferujemy prefiks kolumn z nazwą tabeli. Nie prefiksujemy tabel, ale prefiksujemy widoki (v_) i stored_procedures(sp_ lub f_ (function)). To pomaga ludziom, którzy chcą spróbować upday v_person.wieku, który w rzeczywistości jest polem obliczeniowym w widoku (co nie może być Zaktualizowany w każdym razie).

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

   Sprawia, że kod jest bardziej gadatliwy, 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. To może wymknąć się spod kontroli:

   customer.customer_customer_type_id

   Wskazuje relację między Klientem a tabelą customer_type, wskazuje klucz główny w tabeli customer_type (customer_type_id) i jeśli Kiedykolwiek widzisz 'customer_customer_type_id' podczas debugowania zapytania, od razu wiesz, skąd ono pochodzi(tabela klienta).

   Lub gdzie istnieje relacja M-M między customer_type i customer_category (tylko niektóre typy są dostępne dla niektórych kategorii)

   customer_category_customer_type_id

   ... jest trochę (!) na dłuższym boku.

4. Czy powinienem używać jakiegokolwiek przypadku w nazewnictwie przedmiotów? Tak - małe litery :), z podkreśleniem. Są one bardzo czytelne i wieloplatformowe. Razem z 3 powyżej to również ma sens.

   Większość z nich to jednak preferencje. - Tak długo, jak jesteś konsekwentny, powinien być przewidywalny dla każdego, kto musi go przeczytać.

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

Pisałem o tym jakiś czas temu tutaj: ISO-11179 konwencje nazewnictwa

Cały czas słyszę argument, że to, czy tabela jest pluralizowana, czy nie, jest kwestią osobistego gustu i nie ma najlepszej praktyki. Nie wierzę, że to prawda, zwłaszcza jako programista w przeciwieństwie do DBA. O ile mi wiadomo, nie ma uzasadnionych powodów, aby pluralizować nazwę tabeli inne niż "to po prostu ma sens dla mnie, ponieważ jest to zbiór obiektów", podczas gdy istnieją uzasadnione zyski w kodzie poprzez posiadanie pojedynczych nazw tabel. Na przykład:

1. Informatyka unika błędów i błędów spowodowanych wieloznacznością liczby mnogiej. Programiści nie są do końca znani ze swojej wiedzy ortograficznej, a mnogość niektórych słów jest myląca. Na przykład, czy słowo w liczbie mnogiej kończy się na " es "czy po prostu "s"? Czy to osoby czy ludzie? Gdy pracujesz nad projektem z dużymi zespołami, może to stać się problemem. Na przykład przypadek, w którym członek zespołu używa niepoprawnej metody do wielomianu tworzonej przez siebie tabeli. Do czasu interakcji z tą tabelą, jest ona używana w kodzie I nie mają dostępu do lub zajmie dużo czasu, aby naprawić. W rezultacie muszę pamiętać, aby przeliterować tabelę źle za każdym razem, gdy go używam. Przydarzyło mi się coś bardzo podobnego. Im łatwiej będzie każdemu członkowi zespołu konsekwentnie i łatwo używać dokładnych, poprawnych nazw stołów bez błędów lub konieczności ciągłego wyszukiwania nazw stołów, tym lepiej. Wersja pojedyncza jest znacznie łatwiejsza w obsłudze w środowisku zespołowym.

2. Jeśli używasz pojedynczej wersji a nazwa tabeli i prefiks klucza głównego z nazwą tabeli, teraz masz tę zaletę, że łatwo określasz nazwę tabeli z klucza głównego lub odwrotnie za pomocą samego kodu. Możesz otrzymać zmienną z nazwą tabeli, powiązać "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żywasz "id" bez nazwy tabeli dla podstawowej klucz, wtedy nie można za pomocą kodu określić nazwy tabeli z klucza głównego. Ponadto większość osób, które wielomianują nazwy tabel i prefiks kolumn PK z nazwą tabeli, używa pojedynczej wersji nazwy tabeli w PK( na przykład statusy i statusId), co uniemożliwia to w ogóle.

3. Jeśli nazwy tabel będą pojedyncze, możesz dopasować je do nazw klas, które reprezentują. Po raz kolejny może to uprościć kod i pozwolić ci robić naprawdę schludne rzeczy, takie jak tworzenie instancji klasy przez posiadanie tylko nazwy tabeli. To również po prostu sprawia, że kod bardziej spójne, co prowadzi do...

4. Jeśli nazwa tabeli stanie się pojedyncza, system nazewnictwa będzie spójny, uporządkowany i łatwy w utrzymaniu w każdej lokalizacji. Wiesz, że w każdym przypadku w Twoim kodzie, niezależnie od tego, czy jest to nazwa kolumny, Nazwa klasy, czy nazwa tabeli, jest to dokładnie ta sama nazwa. Pozwala to na wykonywanie globalnych wyszukiwań, aby zobaczyć wszędzie, że dane są używane. Kiedy wielorakie nazwy tabeli, pojawią się przypadki, w których użyjesz pojedynczej wersji tej nazwy tabeli (klasy, do której się zamienia, w kluczu podstawowym). Po prostu ma sens, aby nie mieć niektórych przypadków, w których dane są określane jako liczba mnoga, a niektóre przypadki liczby pojedynczej.

Podsumowując, jeśli wielorakie nazwy tabel tracą wszelkie zalety w uczynieniu kodu mądrzejszym i łatwiejszym w obsłudze. Mogą być nawet przypadki, w których trzeba mieć lookup tabele/tablice do konwersji nazw tabel na nazwy obiektów lub lokalne nazwy kodowe, których można było uniknąć. Nazwy tabel pojedynczych, choć być może czuje się trochę dziwnie na początku, oferują znaczne korzyści w stosunku do nazw mnogich i uważam, że są najlepsze praktyki.

Wiem, że jest późno na grę, a na pytanie już bardzo dobrze odpowiedziałam, ale chciałbym przedstawić swoją opinię na temat # 3 odnośnie prefiksu nazw kolumn.

Wszystkie kolumny powinny być nazwane prefiksem unikalnym dla tabeli, w której są zdefiniowane.

Np. podane tabele "klient" i "adres", dodajmy odpowiednio prefiksy " klient "i " addr". "klient" miałby "cust_id", "cust_name" itp. w nim. "adres" miałby " addr_id", "addr_cust_id" (wróć do klienta), "addr_street" itp. w nim.

Wynikiem tego jest to, że wszystkie kolumny w schemacie bazy danych są unikalne. Jest w tym jedna zasadnicza korzyść, która przebija wszystkie argumenty przeciwko temu (moim zdaniem oczywiście):

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

Korzyść z #1 jest niewiarygodnie Ogromna. Mogę zdeprecjonować kolumnę i dokładnie wiedzieć, jakie pliki muszą być aktualizowane, zanim kolumna może być bezpiecznie usunięta ze schematu. Mogę zmienić znaczenie kolumny i dokładnie wiedzieć, jaki kod należy zrefakturować. Albo mogę po prostu powiedzieć, czy dane z kolumny są nawet używane w określonej części systemu. Nie mogę zliczyć, ile razy to zmieniło potencjalnie ogromny projekt w prosty, ani ile godzin zaoszczędziliśmy na pracach programistycznych.

Kolejną, stosunkowo niewielką korzyścią jest to, że musisz używać aliasów tabel tylko wtedy, gdy robisz SELF join:

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 ten temat to:

1) Nie, nazwy tabel powinny być liczby pojedynczej.

Chociaż wydaje się, że ma to sens dla prostego zaznaczenia (select * from Orders), mniej ma sensu dla odpowiednika OO (Orders x = new Orders).

Tabela w DB jest tak naprawdę zbiorem tej jednostki, ma to większy sens, gdy używasz set-logic:

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

Ta ostatnia linia, faktyczna logika join, wygląda myląco z nazwami tabel liczby mnogiej.

Nie jestem pewien, czy zawsze używasz aliasu (jak sugeruje Matt) wyjaśnij to.

2) powinny być liczby pojedynczej, ponieważ posiadają tylko 1 własność

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

4) cokolwiek chcesz, proponuję CapitalCase

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

Moim zdaniem:

1. nazwy tabel powinny być liczby mnogiej.
2. nazwy kolumn powinny być liczby pojedynczej.
Nie.
3. albo CamelCase (mój preferowany) albo underscore_separated dla nazw tabel i kolumn.

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

1. definitywnie zachowaj nazwy tabel w liczbie pojedynczej, osoba nie ludzie
   1. to samo tutaj
   Nie. Widziałem kilka strasznych przedrostków, posuwających się tak daleko, aby stwierdzić, co miało do czynienia z tabelą (tbl_) lub procedurą sklepu użytkownika (usp_). Po tym następuje nazwa bazy danych... Nie rób tego!
Tak. I tend to PascalCase all my table names

Myślę, że najlepszą odpowiedź na każde z tych pytań udzieliłby Pan i Pański zespół. O wiele ważniejsze jest posiadanie konwencji nazewnictwa niż to, jak dokładnie jest konwencja nazewnictwa.

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

Oczywiście dobrze jest szukać informacji o standardach na ten temat, o co prosisz, ale nie dostajesz niespokojny lub zaniepokojony liczbą różnych odpowiedzi, które możesz uzyskać: wybierz tę, która wydaje się dla ciebie lepsza.

Na wszelki wypadek, oto moje odpowiedzi:

Tak. Tabela jest grupą rekordów, nauczyciele lub aktorzy , więc... liczba mnoga. Tak. Nie używam ich.
1. baza danych, z której korzystam częściej - Firebird-przechowuje wszystko wielkimi literami, więc nie ma to znaczenia. W każdym razie, kiedy programuję piszę nazwy w taki sposób, że jest łatwiejszy do odczytania, jak releaseYear .

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

Dobra konwencja nazewnictwa wymaga czasu, aby ewoluować, ale gdy już jest na swoim miejscu, pozwala zespołowi iść do przodu ze wspólnym językiem. Dobra konwencja nazewnictwa rośnie organicznie wraz z projektem. Dobra konwencja nazewnictwa łatwo radzi sobie ze zmianami w najdłuższej i najważniejszej fazie cyklu życia oprogramowania - zarządzanie usługami w produkcja.

Oto moje odpowiedzi:

1. tak, nazwy tabel powinny być liczby mnogiej, gdy odnoszą się do zbioru transakcji, na przykład papiery wartościowe lub kontrahenci.
Tak. Tak. Tabele SQL są poprzedzone prefiksem tb_, widoki są poprzedzone prefiksem vw_, procedury przechowywane są poprzedzone prefiksem usp_, a wyzwalacze są poprzedzone prefiksem tg_, po którym następuje nazwa bazy danych.
2. Nazwa kolumny powinna być pisana małymi literami oddzielonymi podkreśleniem.

Nazewnictwo jest trudne, ale w każdej organizacji jest ktoś, kto potrafi nazwać rzeczy, a w każdym zespole programistycznym powinien być ktoś, kto bierze odpowiedzialność za standardy nazewnictwa i zapewnia, że kwestie nazewnictwa takie jak sec_id, sec_value i security_id są rozwiązywane wcześnie, zanim zostaną wprowadzone do projektu.

Więc jakie są podstawowe zasady dobrej konwencji nazewnictwa i standardów: -

• Użyj języka swojego klienta i Twoja domena rozwiązania
• Be opisowe
• bądź konsekwentny
• Disambiguate, reflect and refactor
• nie używaj skrótów, chyba że są jasne dla każdego
• nie używaj zarezerwowanych słów kluczowych SQL jako nazwy kolumn

Oto link, który oferuje kilka opcji. Szukałem prostej specyfikacji, którą mógłbym śledzić, zamiast polegać na częściowo zdefiniowanym.

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

Nazwy tabel powinny być zawsze pojedyncze, ponieważ reprezentują zbiór obiektów. Jak mówisz "stado", aby wyznaczyć grupę owiec, lub "stado" oznacza grupę ptaków. Nie potrzeba liczby mnogiej. Gdy nazwa tabeli składa się z dwóch nazw, a konwencja nazewnictwa jest w liczbie mnogiej, trudno jest stwierdzić, czy nazwa w liczbie mnogiej powinna być pierwszym słowem, czy drugim słowem, czy też obydwoma. To obiekt logiczny.instancja, nie Obiekty.przykład. Lub Tableename.kolumny, Nie nazwy tabl.kolumny. Microsoft SQL nie jest przypadkiem wrażliwe, łatwiej jest odczytać nazwy tabel, jeśli używane są duże litery, 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ą pojedyncze.

Nazwa kolumny: powinna być pojedyncza tylko wtedy, gdy przekazuje, że będzie posiadać wartość atomową i potwierdzi teorię normalizacji. Jeśli jednak istnieje n liczb tego samego typu właściwości, to powinny one być zakończone przez 1, 2, ..., n, itp.

Prefiksowanie tabel / kolumn: jest to ogromny temat, omówi później.

Obudowa: it should be Camel case

Mój przyjacielu, Patrick Karcher , proszę cię, abyś nie pisał niczego, co może być dla kogoś obraźliwe, jak napisałeś, " * ponadto klucze obce muszą być nazwane konsekwentnie w różnych tabelach. Bicie kogoś, kto tego nie robi, powinno być legalne.". Nigdy nie zrobiłem tego błędu Mój przyjaciel Patrick, ale piszę ogólnie. A jeśli razem planują cię za to pokonać? :)

Bardzo późno na imprezę, ale i tak chciałem dodać moje dwa grosze o przedrostkach kolumn

Wydaje się, że istnieją dwa główne argumenty przemawiające za używaniem standardu nazw table_column (lub tableColumn) dla kolumn, oba oparte na fakcie, że sama nazwa kolumny będzie unikalna w całej bazie danych:

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

2) możesz łatwo wyszukać cały kod dla nazwy kolumny

I myślę, że oba argumenty są wadliwe. 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 tabeli.kolumna zamiast kolumny.

To oczywiście rozwiązuje 2) Jak można teraz po prostu szukać tabeli.kolumna zamiast table_column.

Ale słyszę twój krzyk, jak to rozwiązuje 1)? Chodziło dokładnie o uniknięcie tego. Tak, było, ale rozwiązanie było strasznie wadliwe. Dlaczego? Cóż, rozwiązanie prefiksu sprowadza się do:
Aby uniknąć konieczności podawania tabeli.kolumna gdy jest niejednoznaczność, nazwiesz wszystkie kolumny table_column!
Oznacza to jednak, że od teraz zawsze będziesz musiał pisać nazwę kolumny za każdym razem, gdy podasz kolumnę. Ale jeśli musisz to zrobić tak czy inaczej, jaka jest korzyść z zawsze jawnie pisanie tabeli.kolumna? Dokładnie, nie ma żadnych korzyści, to dokładnie taka sama liczba znaków do wpisania.

Edit: tak, zdaję sobie sprawę, że nazywanie kolumn prefiks wymusza poprawne użycie, podczas gdy moje podejście opiera się na programistach

Podstawowe konwencje nazewnictwa baz danych (i Style) (Kliknij tutaj, aby uzyskać bardziej szczegółowy opis)

Nazwy tabel wybierz krótkie, jednoznaczne nazwy, używając nie więcej niż jednego lub dwóch słów łatwe rozróżnianie tabel ułatwia nazywanie unikalnych nazw pól, a także wyszukiwanie i łączenie tabel podaj nazwy tabel w liczbie pojedynczej, nigdy w liczbie mnogiej (aktualizacja: nadal zgadzam się z powodami podanymi dla tej konwencji ,ale większość ludzi naprawdę lubi nazwy tabel w liczbie mnogiej, więc zmiękczyłem moje stanowisko)... kliknij powyższy link

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

Nazwy tabel liczby pojedynczej. Powiedzmy, że modelowałeś związek między kimś a jego adresem. Na przykład, jeśli czytasz datamodel, czy wolisz "każda osoba może mieszkać pod adresem 0,1 lub wielu."lub "każdy człowiek może mieszkać pod adresem 0,1 lub wielu adresów.' Myślę, że łatwiej jest urozmaicić adres, niż przeformułować ludzi jako osoby. Plus rzeczowniki zbiorowe są dość często dissimlar do wersji pojedynczej.

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

To są konwencje, których mnie uczono, ale powinieneś dostosować się do tego, czego używasz.

1. liczba mnoga. Jest to zbiór Bytów.
Tak. Atrybut jest reprezentacją pojedynczej własności podmiotu.
2. tak, prefiks nazwa tabeli umożliwia łatwe śledzenie nazw wszystkich indeksów ograniczeń i aliasów tabel.
3. przypadek Pascala dla nazw tabel i kolumn, prefiks + wszystkie caps dla indeksów i ograniczeń.