Rozpoczynam nowy projekt i chciałbym uzyskać od samego początku nazwy moich tabel i kolumn. Na przykład zawsze używałem liczby mnogiej w nazwach tabel, ale ostatnio dowiedziałem się, że liczba pojedyncza jest poprawna.

Tak więc, jeśli mam tabelę „user”, a następnie otrzymam produkty, które będzie miał tylko użytkownik, czy tabela powinna mieć nazwę „user_product” czy po prostu „product”? To jest relacja jeden do wielu.

I dalej, gdybym miał (z jakiegoś powodu) kilka opisów produktów dla każdego produktu, czy byłoby to „user_product_description”, „product_description” czy po prostu „description”? Oczywiście z ustawionymi odpowiednimi kluczami obcymi. Nadanie mu nazwy tylko opis byłoby problematyczne, ponieważ mógłbym mieć również opis użytkownika lub opis konta lub cokolwiek innego.

A co jeśli chcę mieć czystą tabelę relacyjną (wiele do wielu) z tylko dwiema kolumnami, jak by to wyglądało? „user_stuff” czy może coś w rodzaju „rel_user_stuff”? A jeśli pierwszy, co by to odróżniało od np. „User_product”?

Każda pomoc jest bardzo ceniona, a jeśli istnieje jakiś standard konwencji nazewnictwa, który polecacie, nie krępuj się, aby go połączyć.

Dzięki

Nazwa tabeli

niedawno nauczona liczba pojedyncza jest poprawna

Tak. Strzeżcie się pogan. Liczba mnoga w nazwach tabel to pewny znak kogoś, kto nie przeczytał żadnego ze standardowych materiałów i nie ma wiedzy o teorii baz danych.

Oto niektóre ze wspaniałych cech Standardów:

• wszystkie są ze sobą zintegrowane
• Oni pracują razem
• zostały napisane przez umysły większe niż nasze, więc nie musimy o nich dyskutować.

Standardowa nazwa tabeli odnosi się do każdego wiersza w tabeli, która jest używana we wszystkich słowach, a nie do całej zawartości tabeli (wiemy, że Customertabela zawiera wszystkich Klientów).

Związek, zwrot czasownika

W prawdziwych relacyjnych bazach danych, które zostały zamodelowane (w przeciwieństwie do systemów archiwizacji rekordów sprzed lat 70. XX wieku [charakteryzujących się Record IDstym, że dla wygody zaimplementowano je w kontenerze bazy danych SQL):

• tabele są podmiotami bazy danych, a więc są rzeczownikami , znowu w liczbie pojedynczej
• relacje między tabelami są akcjami, które mają miejsce między rzeczownikami, a więc są to czasowniki (tj. nie są arbitralnie numerowane ani nazwane)
• że jest Predicate
• wszystko, co można odczytać bezpośrednio z modelu danych (patrz moje przykłady na końcu)
• (Predykat dla niezależnej tabeli (najwyższego elementu nadrzędnego w hierarchii) jest taki, że jest niezależny)
• w związku z tym fraza czasownika jest starannie dobrana, tak aby była jak najbardziej znacząca i aby uniknąć ogólnych terminów (staje się to łatwiejsze wraz z doświadczeniem). Fraza czasownika jest ważna podczas modelowania, ponieważ pomaga w rozwiązaniu modelu, tj. wyjaśnianie relacji, identyfikowanie błędów i poprawianie nazw tabel.

Diagram_A

Oczywiście relacja jest zaimplementowana w języku SQL jako a CONSTRAINT FOREIGN KEYw tabeli potomnej (więcej, później). Oto fraza czasownika (w modelu), predykat, który reprezentuje (do odczytania z modelu) i nazwa ograniczenia FK :

    Initiates
    Each Customer Initiates 0-to-n SalesOrders
    Customer_Initiates_SalesOrder_fk

Tabela • Język

Jednak podczas opisywania tabeli, szczególnie w języku technicznym, takim jak predykaty lub inna dokumentacja, używaj liczby pojedynczej i mnogiej, ponieważ naturalnie w języku angielskim. Mając na uwadze, że nazwa tabeli pochodzi od pojedynczego wiersza (relacji), a język odnosi się do każdego wiersza pochodnego (relacja pochodna):

    Each Customer initiates zero-to-many SalesOrders

nie

    Customers have zero-to-many SalesOrders 

Tak więc, jeśli mam tabelę „user”, a następnie otrzymam produkty, które będzie miał tylko użytkownik, czy tabela powinna nazywać się „user-product” czy po prostu „product”? To jest relacja jeden do wielu.

(To nie jest kwestia nazewnictwa; to jest kwestia projektowania db.) Nie ma znaczenia, czy user::productjest to 1 :: n. Liczy się to, czy productjest to odrębny byt i czy jest to Niezależna Tabela , tj. może istnieć samodzielnie. Dlatego productnie user_product.

A jeśli productistnieje tylko w kontekście user, tj. jest to zatem tabela zależnauser_product .

Diagram_B

I dalej, gdybym miał (z jakiegoś powodu) kilka opisów produktów dla każdego produktu, czy byłby to „opis produktu użytkownika”, „opis produktu” czy po prostu „opis”? Oczywiście z odpowiednimi kluczami obcymi. Nadanie mu nazwy tylko opis byłoby problematyczne, ponieważ mógłbym mieć również opis użytkownika lub opis konta lub cokolwiek innego.

Zgadza się. Każdy user_product_descriptionxor product_descriptionbędzie poprawny, na podstawie powyższego. Nie ma go odróżniać od innych xxxx_descriptions, ale ma nadać nazwie poczucie, gdzie należy, a przedrostkiem jest tabela nadrzędna.

A co jeśli chcę mieć czystą tabelę relacyjną (wiele do wielu) z tylko dwiema kolumnami, jak by to wyglądało? „rzeczy użytkownika” czy może coś w rodzaju „rzeczy rel-użytkownika”? A jeśli pierwszy, co by to odróżniało od np. „Produktu użytkownika”?

1. Miejmy nadzieję, że wszystkie tabele w relacyjnej bazie danych są czysto relacyjnymi, znormalizowanymi tabelami. Nie ma potrzeby identyfikowania tego w nazwie (w przeciwnym razie wszystkie tabele będą rel_something).

2. Jeśli zawiera tylko PK dwóch rodziców (co rozwiązuje logiczną relację n :: n, która nie istnieje jako jednostka na poziomie logicznym, do fizycznej tabeli), jest to tabela asocjacyjna . Tak, zazwyczaj nazwa jest połączeniem dwóch nazw tabel nadrzędnych.

   • Zauważ, że w takich przypadkach fraza czasownika ma zastosowanie i jest odczytywana jako, od rodzica do rodzica, ignorując tabelę podrzędną, ponieważ jej jedynym celem w życiu jest powiązanie dwojga rodziców.

     Diagram_C

   • Jeśli to nie tabeli asocjacyjne (tj. W uzupełnieniu do dwóch PK, zawiera dane), a następnie na to odpowiednie, i zwroty Verb odnoszą się do niego, a nie z rodziców na końcu związku.

     Diagram_D

3. Jeśli otrzymasz dwie user_producttabele, oznacza to bardzo głośny sygnał, że dane nie zostały znormalizowane. Cofnij się więc o kilka kroków i zrób to, a następnie nazwij tabele dokładnie i konsekwentnie. Nazwy same się rozwiążą.

Konwencja nazewnictwa

Każda pomoc jest bardzo ceniona, a jeśli istnieje jakiś standard konwencji nazewnictwa, który polecacie, nie krępuj się, aby go połączyć.

To, co robisz, jest bardzo ważne i wpłynie na łatwość użytkowania i zrozumienie na każdym poziomie. Dlatego dobrze jest na początku uzyskać jak najwięcej zrozumienia. Znaczenie większości z nich nie będzie jasne, dopóki nie zaczniesz kodować w języku SQL.

1. Sprawa to pierwsza rzecz, którą należy się zająć. Wszystkie czapki są niedopuszczalne. Wielkość liter jest normalna, zwłaszcza jeśli użytkownicy mają bezpośredni dostęp do tabel. Zapoznaj się z moimi modelami danych. Zauważ, że kiedy osoba poszukująca używa obłąkanego NonSQL, który ma tylko małe litery, daję to, w takim przypadku dołączam podkreślenia (jak na twoich przykładach).

2. Skup się na danych , a nie na aplikacji lub użyciu. W końcu 2011 roku mamy otwartą architekturę od 1984 roku, a bazy danych mają być niezależne od aplikacji, które z nich korzystają.

   W ten sposób, gdy rosną i więcej niż jedna aplikacja ich używa, nazewnictwo pozostanie znaczące i nie będzie wymagało korekty. (Bazy danych, które są całkowicie osadzone w jednej aplikacji, nie są bazami danych). Nazwij elementy danych tylko jako dane.

3. Bądź bardzo rozważny i bardzo dokładnie nazywaj tabele i kolumny . Nie używaj, UpdatedDatejeśli jest to DATETIMEtyp danych, użyj UpdatedDtm. Nie używać, _descriptionjeśli zawiera dawkę.

4. Ważne jest, aby zachować spójność w całej bazie danych. Nie używaj NumProductw jednym miejscu do wskazania liczby Produktów ItemNoani ItemNumw innym miejscu do wskazania liczby Produktów. Używaj konsekwentnie NumSomethingdo numerów-of i SomethingNolub SomethingIddo identyfikatorów.

5. Nie poprzedzaj nazwy kolumny nazwą tabeli ani krótkim kodem, takim jak user_first_name. SQL już podaje nazwę tabeli jako kwalifikator:

       table_name.column_name  -- notice the dot
   

6. Wyjątki:

   • Pierwszy wyjątek dotyczy PK, wymagają one specjalnej obsługi, ponieważ cały czas kodujesz je w złączeniach i chcesz, aby klucze wyróżniały się z kolumn danych. Zawsze używaj user_id, nigdy id.

     • Należy pamiętać, że to nie nazwa tabeli stosowany jako przedrostek, ale właściwa nazwa opisowa dla komponentu klucza: user_idjest kolumna, która identyfikuje użytkownika, a nie idna userstole.
       • (Z wyjątkiem oczywiście zbiorów akt, gdzie dostęp do plików mają surogaty i nie ma kluczy relacyjnych, tam są jedno i to samo).
     • Zawsze używaj dokładnie tej samej nazwy dla kolumny klucza wszędzie tam, gdzie PK jest przenoszony (migrowany) jako FK.
     • Dlatego user_producttabela będzie miała user_idjako składnik swojej PK (user_id, product_no).
     • znaczenie tego stanie się jasne, gdy zaczniesz kodować. Po pierwsze, mając idna wielu tabelach, łatwo jest pomylić kodowanie SQL. Po drugie, każdy inny, kto pierwszy programista nie ma pojęcia, co próbował zrobić. Oba są łatwe do uniknięcia, jeśli kolumny kluczowe są traktowane jak powyżej.

   • Drugim wyjątkiem jest sytuacja, gdy istnieje więcej niż jeden FK odwołujący się do tej samej tabeli tabeli nadrzędnej, przenoszonej przez element podrzędny. Zgodnie z modelem relacyjnym , użyj nazw ról, aby rozróżnić znaczenie lub użycie, np. AssemblyCodei ComponentCodedla dwojga PartCodes. W takim przypadku nie używaj niezróżnicowanego PartCodedla jednego z nich. Bądź precyzyjny.

     Diagram_E

7. Prefiks
   Jeśli masz więcej niż 100 tabel, poprzedź nazwy tabel obszarem tematu:

   REF_dla tabel referencyjnych
   OE_dla klastra wprowadzania zamówień itp.

   Tylko na poziomie fizycznym, a nie logicznym (zaśmieca model).

8. Sufiks
   Nigdy nie używaj sufiksów w tabelach i zawsze używaj sufiksów do wszystkiego innego. Oznacza to, że przy logicznym, normalnym korzystaniu z bazy danych nie ma podkreślenia; ale po stronie administracyjnej podkreślenia są używane jako separator:

   _VWidok ( TableNameoczywiście z głównym z przodu)
   _fkKlucz obcy (nazwa ograniczenia, a nie nazwa kolumny) Transakcja segmentu
   _cacpamięci podręcznej (przechowywana procedura lub funkcja) Funkcja (nietransakcyjna) itp.
   _seg
_tr
_fn

   Format to nazwa tabeli lub FK, podkreślenie i nazwa akcji, podkreślenie i na końcu sufiks.

   Jest to naprawdę ważne, ponieważ gdy serwer wyświetla komunikat o błędzie:

   ____blah blah blah error on object_name

   wiesz dokładnie, jaki obiekt został naruszony i co próbował zrobić:

   ____blah blah blah error on Customer_Add_tr

9. Klucze obce (ograniczenie, a nie kolumna). Najlepszym nazewnictwem FK jest użycie wyrażenia czasownika (bez „każdego” i liczności).

   Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk

   Użyj Parent_Child_fksekwencji, a nie Child_Parent_fkjest, ponieważ (a) pojawia się ona we właściwej kolejności, kiedy ich szukasz, i (b) zawsze wiemy, jakie dziecko jest zaangażowane, co zgadujemy, który rodzic. Komunikat o błędzie jest wtedy zachwycający:

   ____ Foreign key violation on Vendor_Offers_PartVendor_fk.

   To działa dobrze dla osób, które zadają sobie trud modelowania swoich danych, w których zidentyfikowano wyrażenia czasownikowe. W pozostałej części użyj zbiorów akt itp Parent_Child_fk.

10. Indeksy są specjalne, więc mają własną konwencję nazewnictwa, na którą składają się kolejno pozycje każdego znaku od 1 do 3:

    UUnikalny lub _nieunikatowy Separator
    Cklastrowy lub _nieklastrowy
    _

    Dla przypomnienia:

    • Jeśli klucz to jedna kolumna lub kilka kolumn:
      ____ColumnNames

    • Jeśli klucz ma więcej niż kilka kolumn:
      ____ PKKlucz podstawowy (zgodnie z modelem)
      ____ AK[*n*]Klucz alternatywny (termin IDEF1X)

    Zwróć uwagę, że nazwa tabeli nie jest wymagana w nazwie indeksu, ponieważ zawsze jest wyświetlana jakotable_name.index_name.

    Więc kiedy Customer.UC_CustomerIdlub Product.U__AKpojawia się w komunikacie o błędzie, mówi ci coś znaczącego. Gdy spojrzysz na indeksy na stole, możesz je łatwo rozróżnić.

11. Znajdź kogoś wykwalifikowanego i profesjonalnego i podążaj za nimi. Przyjrzyj się ich projektom i dokładnie przestudiuj konwencje nazewnictwa, których używają. Zadawaj im konkretne pytania dotyczące wszystkiego, czego nie rozumiesz. I na odwrót, uciekaj jak diabli od każdego, kto wykazuje niewielki szacunek dla konwencji lub standardów nazewnictwa. Oto kilka na początek:

    • Zawierają prawdziwe przykłady wszystkich powyższych. Zadawaj pytania zmieniające nazwy pytań w tym wątku.
    • Oczywiście modele implementują kilka innych standardów, wykraczających poza konwencje nazewnictwa; możesz na razie je zignorować lub zadawać nowe pytania .
    • Każda z nich ma kilka stron, obsługa obrazów w wierszu Stack Overflow jest przeznaczona dla ptaków i nie ładują się one konsekwentnie w różnych przeglądarkach; więc będziesz musiał kliknąć linki.
    • Zwróć uwagę, że pliki PDF mają pełną nawigację, więc kliknij niebieskie szklane przyciski lub obiekty, w których zidentyfikowano rozszerzenie:
    • Czytelnicy, którzy nie są zaznajomieni ze standardem modelowania relacyjnego, mogą uznać notację IDEF1X za pomocną.

Zamówienia i zapasy z adresami zgodnymi z normami

Prosty system biuletynów biurowych dla PHP / MyNonSQL

Monitorowanie czujnika z pełną funkcją Temporal

Odpowiedzi na pytania

^{Na to nie można rozsądnie odpowiedzieć w polu komentarza.}

Larry Lustig:
... nawet najbardziej trywialny przykład pokazuje ...
Jeśli Klient ma Produkty typu zero do wielu, a Produkt ma Składniki jeden do wielu, a Składnik ma Dostawców jeden do wielu, a Dostawca sprzedaje zero -to-many Components, a SalesRep ma jeden do wielu klientów, jakie są „naturalne” nazwy tabel zawierających klientów, produkty, komponenty i dostawców?

W Twoim komentarzu są dwa główne problemy:

1. Oświadczasz, że twój przykład jest „najbardziej trywialny”, jednak jest to wszystko inne. Z tego rodzaju sprzecznościami nie jestem pewien, czy jesteś poważny, czy technicznie zdolny.

2. Ta „trywialna” spekulacja zawiera kilka poważnych błędów normalizacji (projektowania DB).

   • Dopóki ich nie poprawisz, są nienaturalne i nienormalne i nie mają żadnego sensu. Równie dobrze możesz nazwać je nienormalne_1, anormalne_2 itd.

   • Masz „dostawców”, którzy niczego nie dostarczają; odwołania cykliczne (nielegalne i niepotrzebne); klienci kupujący produkty bez żadnego instrumentu komercyjnego (takiego jak faktura lub zamówienie sprzedaży) jako podstawy do zakupu (czy też klienci „posiadają” produkty?); nierozwiązane relacje „wiele do wielu”; itp.

   • Po znormalizowaniu i zidentyfikowaniu wymaganych tabel ich nazwy staną się oczywiste. Naturalnie.

W każdym razie postaram się obsłużyć Twoje zapytanie. Co oznacza, że ​​będę musiał nadać temu trochę sensu, nie wiedząc, co masz na myśli, więc proszę o wyrozumiałość. Jest zbyt wiele poważnych błędów, aby je wymienić, a biorąc pod uwagę niepełną specyfikację, nie jestem pewien, czy poprawiłem je wszystkie.

• Zakładam, że jeśli produkt składa się z komponentów, to produkt jest zespołem, a komponenty są używane w więcej niż jednym zespole.

• Ponadto, ponieważ „Dostawca sprzedaje komponenty od zera do wielu”, nie sprzedaje produktów ani zespołów, sprzedaje tylko komponenty.

Spekulacje a model znormalizowany

Jeśli nie jesteś świadomy, różnica między narożnikami kwadratowymi (niezależne) i zaokrąglonymi (zależne) jest znacząca, zapoznaj się z linkiem Notation IDEF1X. Podobnie linie ciągłe (identyfikujące) w porównaniu z liniami przerywanymi (nieidentyfikujące).

... jakie są „naturalne” nazwy tabel zawierających klientów, produkty, komponenty i dostawców?

• Klient
• Produkt
• Komponent (lub AssemblyComponent, dla tych, którzy zdają sobie sprawę, że jeden fakt identyfikuje drugi)
• Dostawca

Teraz, gdy rozwiązałem tabele, nie rozumiem twojego problemu. Być może możesz zadać konkretne pytanie.

VoteCoffee:
Jak sobie radzisz ze scenariuszem, który Ronnis opublikował w swoim przykładzie, w którym istnieje wiele relacji między 2 tabelami (user_likes_product, user_bought_product)? Mogę źle zrozumieć, ale wydaje się, że skutkuje to zduplikowanymi nazwami tabel przy użyciu konwencji, którą opisałeś.

Zakładając, że nie ma błędów normalizacji, User likes Productjest predykatem, a nie tabelą. Nie myl ich. Zapoznaj się z moją odpowiedzią, gdzie odnosi się do tematów, czasowników i orzeczeń, oraz moją odpowiedź dla Larry'ego bezpośrednio powyżej.

• Każda tabela zawiera zestaw faktów (każdy wiersz to fakt). Predykaty (lub zdania) nie są faktami, mogą być prawdziwe lub nie.

  • Relacyjny model jest oparty na rachunku predykatów pierwszego (bardziej znany jako pierwsze zamówienie Logic). Predykat to zdanie składające się z pojedynczej klauzuli w prostym, precyzyjnym języku angielskim, którego wynikiem jest prawda lub fałsz.

  • Co więcej, każda tabela reprezentuje lub jest implementacją wielu Predykatów, a nie jednego.

• Zapytanie to test Predykatu (lub pewnej liczby Predykatów połączonych w łańcuch), którego wynikiem jest prawda (Fakt istnieje) lub fałsz (Fakt nie istnieje).

• Dlatego tabele powinny być nazywane zgodnie z moją odpowiedzią (konwencje nazewnictwa), dla wiersza, fakt i predykaty powinny być udokumentowane (jak najbardziej jest to część dokumentacji bazy danych), ale jako osobna lista Predykatów .

• To nie jest sugestia, że ​​nie są one ważne. Są bardzo ważne, ale nie napiszę tego tutaj.

• Więc szybko. Ponieważ model relacyjny jest oparty na FOPC, o całej bazie danych można powiedzieć, że jest zbiorem deklaracji FOPC, zbiorem predykatów. Ale (a) istnieje wiele typów Predykatów i (b) tabela nie reprezentuje jednego Predykatu (jest to fizyczna implementacja wielu Predykatów i różnych typów Predykatów).

• Dlatego nazwanie tabeli „orzeczeniem, które reprezentuje” jest absurdalną koncepcją.

• „Teoretycy” są świadomi tylko kilku Predykatów, nie rozumieją, że skoro RM została założona na FOL, cała baza danych jest zbiorem Predykatów i jest różnych typów.

  • I oczywiście wybierają absurdalne spośród nielicznych, które znają EXISTING_PERSON:; PERSON_IS_CALLED. Gdyby to nie było takie smutne, byłoby przezabawne.

  • Zauważ również, że standardowa lub atomowa nazwa tabeli (nazywająca wiersz) działa doskonale w przypadku wszystkich wyrażeń (w tym wszystkich predykatów dołączonych do tabeli). I odwrotnie, idiotyczna „tabela reprezentuje predykat” nie może. Co jest dobre dla „teoretyków”, którzy niewiele rozumieją o orzeczeniach, ale mają inne opóźnienie.

• Predykaty, które są istotne dla modelu danych, są wyrażone w modelu, mają dwa rzędy.

  1. Jednoargumentowy predykat
     Pierwszy zestaw jest schematyczny , a nie tekstowy: sam zapis . Należą do nich różne egzystencjalne; Zorientowany na ograniczenia; i Predykaty deskryptorowe (atrybuty).

     • Oczywiście oznacza to, że tylko ci, którzy potrafią „czytać” standardowy model danych, mogą czytać te predykaty. Z tego powodu „teoretycy”, którzy są poważnie ułomni z powodu swojego nastawienia wyłącznie na tekst, nie mogą czytać modeli danych, dlatego trzymają się sposobu myślenia sprzed 1984 roku.

  2. Predykat binarny
     Drugi zestaw to te, które tworzą relacje między faktami. To jest linia relacji. Fraza czasownika (szczegółowo opisana powyżej) identyfikuje predykat, zdanie , które zostało zaimplementowane (które można sprawdzić za pomocą zapytania). Nie można wyrazić się bardziej wprost.

     • Dlatego dla osoby biegłej w standardowych modelach danych wszystkie istotne Predykaty są udokumentowane w modelu. Nie potrzebują osobnej listy Predykatów (ale użytkownicy, którzy nie mogą „czytać” wszystkiego z modelu danych, robią!).

• Oto model danych , w którym wymieniłem predykaty. Wybrałem ten przykład, ponieważ pokazuje on predykaty egzystencjalne itp., A także predykaty relacyjne, jedynymi predykatami, które nie zostały wymienione, są deskryptory. Tutaj, ze względu na poziom wiedzy poszukiwacza, traktuję go jako użytkownika.

Dlatego zdarzenie więcej niż jednej tabeli podrzędnej między dwiema tabelami nadrzędnymi nie stanowi problemu, po prostu nazwij je jako fakt egzystencjalny w ich zawartości i znormalizuj nazwy.

Reguły, które podałem dla wyrażeń czasownikowych dla nazw relacji dla tabel asocjacyjnych, wchodzą tutaj w grę. Oto podsumowanie dyskusji Predykat vs Tabela , obejmującej wszystkie wspomniane punkty.

Aby uzyskać dobry krótki opis właściwego używania predykatów i sposobu ich używania (co jest całkiem innym kontekstem niż odpowiadanie na komentarze tutaj), odwiedź tę odpowiedź i przewiń w dół do sekcji Predykaty .

Charles Burns:
Przez sekwencję miałem na myśli obiekt w stylu Oracle używany wyłącznie do przechowywania liczby i jej następnej zgodnie z jakąś regułą (np. „Dodaj 1”). Ponieważ Oracle nie ma tabel z automatycznym identyfikatorem, moim typowym zastosowaniem jest generowanie unikalnych identyfikatorów dla tabel PK. INSERT INTO foo (id, somedata) VALUES (foo_s.nextval, "data" ...)

Ok, to właśnie nazywamy tabelą Key lub NextKey. Nazwij to tak. Jeśli masz SubjectAreas, użyj COM_NextKey, aby wskazać, że jest wspólny dla całej bazy danych.

Przy okazji, to bardzo słaba metoda generowania kluczy. W ogóle nie jest skalowalny, ale z wydajnością Oracle prawdopodobnie jest „po prostu w porządku”. Co więcej, wskazuje, że twoja baza danych jest pełna surogatów, a nie relacyjnych w tych obszarach. Co oznacza wyjątkowo słabą wydajność i brak integralności.

Liczba pojedyncza a liczba mnoga: Wybierz jedną i trzymaj się jej.

Kolumny nie powinny być poprzedzane / sufiksowane / wrostane ani w żaden sposób poprawiane z odniesieniami do faktu, że jest to kolumna. To samo dotyczy stołów. Nie nazywaj tabel EMPLOYEE_T ani TBL_EMPLOYEES, ponieważ w drugiej kolejności jest zastępowana widokiem, sprawy stają się naprawdę zagmatwane.

Nie osadzaj informacji o typie w nazwach, takich jak „vc_firstname” dla varchar lub „flavour_enum”. Nie osadzaj też ograniczeń w nazwach kolumn, takich jak „dział_fk” lub „pracownik_pk”.

Właściwie jedyną dobrą rzeczą * Poprawki można myślę, jest to, że można używać zarezerwowanych słów takich jak where_t, tbl_order, user_vw. Oczywiście w tych przykładach użycie liczby mnogiej rozwiązałoby problem :)

Nie nazywaj wszystkich kluczy „ID”. Klucze odnoszące się do tej samej rzeczy powinny mieć tę samą nazwę we wszystkich tabelach. Kolumna identyfikatora użytkownika może mieć nazwę USER_ID w tabeli użytkowników i wszystkich tabelach odwołujących się do użytkownika. Zmiana nazwy następuje tylko wtedy, gdy różni użytkownicy odgrywają różne role, na przykład Message (sender_user_id, receiver_user_id). To naprawdę pomaga w przypadku większych zapytań.

Odnośnie CaSe:

thisiswhatithinkofalllowercapscolumnnames.

ALLUPPERCAPSISNOTBETTERBECAUSEITFEELSLIKESOMEONEISSCREAMINGATME.

CamelCaseIsMarginallyBetterButItStillTakesTimeToParse.    

i_recommend_sticking_with_lower_case_and_underscore

Ogólnie lepiej jest nazwać „tabele odwzorowań”, aby pasowały do ​​relacji, które opisują, zamiast nazw tabel, do których istnieją odniesienia. Użytkownik może mieć dowolną liczbę relacji do produktów: user_likes_product, user_bought_product, user_wants_to_buy_product.

Nie ma „poprawności” w liczbie pojedynczej i mnogiej - jest to głównie kwestia gustu.

Po części zależy to od twojego skupienia. Jeśli myślisz o tabeli jako jednostce, zawiera ona `` liczbę mnogą '' (ponieważ zawiera wiele wierszy - więc nazwa w liczbie mnogiej jest odpowiednia). Jeśli myślisz o nazwie tabeli jako identyfikującej wiersz w tabeli, wolisz „liczbę pojedynczą”. Oznacza to, że twój SQL będzie traktowany jako pracujący na jednym wierszu z tabeli. To jest OK, choć zwykle jest to nadmierne uproszczenie; SQL działa na zbiorach (mniej więcej). Jednak w przypadku odpowiedzi na to pytanie możemy użyć liczby pojedynczej.

1. Ponieważ prawdopodobnie będziesz potrzebować tabeli „user”, innego „produktu” i trzeciego do łączenia użytkowników z produktami, potrzebujesz tabeli „user_product”.

2. Ponieważ opis dotyczy produktu, należy użyć „opis_produktu”. Chyba że każdy użytkownik nazwałby każdy produkt dla siebie ...

3. Tabela „user_product” jest (lub może być) przykładem tabeli z identyfikatorem produktu i identyfikatorem użytkownika i niewiele więcej. Nazwij tabele z dwoma atrybutami w ten sam ogólny sposób: „user_stuff”. Dekoracyjne przedrostki, takie jak „rel_”, tak naprawdę nie pomagają. Na przykład niektóre osoby używają „t_” przed nazwą każdej tabeli. To niewiele pomaga.

Liczba mnoga nie jest zła, o ile jest używana konsekwentnie - ale wolę liczbę pojedynczą.

Zrezygnowałbym z podkreślenia, chyba że chcesz nakreślić relację wiele do wielu; i używaj kapitału początkowego, ponieważ pomaga to odróżnić rzeczy w ORMach.

Ale istnieje wiele konwencji nazewnictwa, więc jeśli chcesz używać podkreśleń, jest to w porządku, o ile jest to wykonywane konsekwentnie.

Więc:

User

UserProduct (it is a users products after all)

Jeśli tylko jeden użytkownik może mieć dowolny produkt

UserProductDescription

Ale jeśli produkt jest udostępniany przez użytkowników:

ProductDescription

Jeśli zapiszesz podkreślenia dla relacji wiele do wielu, możesz zrobić coś takiego:

UserProduct_Stuff

aby utworzyć M-to-M między UserProduct a Stuff - nie jestem pewien, z pytania, jaki jest dokładny charakter wymaganej liczby do wielu.

Nie ma lepszego sposobu na użycie liczby pojedynczej niż liczba mnoga. Gdzie to słyszałeś? Powiedziałbym raczej, że liczba mnoga jest bardziej powszechna w nazewnictwie tabel bazy danych ... i moim zdaniem jest też bardziej logiczna. Tabela najczęściej zawiera więcej niż jeden wiersz;) W modelu koncepcyjnym chociaż nazwy jednostek są często w liczbie pojedynczej.

Jeśli chodzi o twoje pytanie, jeśli „Produkt” i „Opis produktu” są pojęciami z tożsamością (tj. Bytami) w Twoim modelu, nazwałbym tabele „Produkty” i „Opisy produktów”. W przypadku tabel używanych w celu zaimplementowania relacji wiele-do-wielu najczęściej używam konwencji nazewnictwa „SideA2SideB”, na przykład „Student2Course”.