Konwencja nazewnictwa klucza podstawowego / klucza obcego [zamknięta]

W naszej grupie deweloperów toczymy zaciekłą debatę dotyczącą konwencji nazewnictwa kluczy podstawowych i obcych. W naszej grupie są zasadniczo dwie szkoły myślenia:

1:

Primary Table (Employee)   
Primary Key is called ID

Foreign table (Event)  
Foreign key is called EmployeeID

lub

2:

Primary Table (Employee)  
Primary Key is called EmployeeID

Foreign table (Event)  
Foreign key is called EmployeeID

Wolę nie powielać nazwy tabeli w żadnej z kolumn (więc wolę opcję 1 powyżej). Koncepcyjnie jest to zgodne z wieloma zalecanymi praktykami w innych językach, w których nie używa się nazwy obiektu w nazwach jego właściwości. Myślę, że nazwanie klucza obcego EmployeeID(a Employee_IDmoże lepiej) mówi czytelnikowi, że jest to IDkolumna Employeetabeli.

Inni wolą opcję 2, w której nazwa klucza podstawowego jest poprzedzona nazwą tabeli, tak aby nazwa kolumny była taka sama w całej bazie danych. Rozumiem, ale teraz nie możesz wizualnie odróżnić klucza podstawowego od klucza obcego.

Myślę też, że nie ma sensu umieszczać nazwy tabeli w nazwie kolumny, ponieważ jeśli myślisz o tabeli jako o encji, a kolumna jako o właściwości lub atrybucie tej jednostki, myślisz o tym jako o atrybucie identyfikatora elementu Employee, a nie EmployeeIDatrybut pracownika. Nie chodzę ASK mojego współpracownika co jego PersonAgelub PersonGenderIS. Pytam go, jaki jest jego wiek.

Tak więc, jak powiedziałem, jest to zaciekła debata i ciągle o tym mówimy. Jestem zainteresowany, aby uzyskać nowe perspektywy.

To nie ma znaczenia. Nigdy nie spotkałem systemu, w którym istnieje prawdziwa różnica między wyborem 1 a wyborem 2.

Jeff Atwood miał jakiś świetny artykuł na ten temat. Zasadniczo ludzie dyskutują i dyskutują najbardziej wściekle na tematy, w których nie można im udowodnić, że się mylą. Albo z innego punktu widzenia, na te tematy, które można wygrać tylko dzięki argumentom ostatniego człowieka, opartym na wytrwałości w stylu obstrukcji.

Wybierz jeden i powiedz im, aby skupili się na problemach, które faktycznie mają wpływ na Twój kod.

EDYCJA: Jeśli chcesz się dobrze bawić, poproś ich, aby szczegółowo określili, dlaczego ich metoda jest lepsza w przypadku rekurencyjnych odwołań do tabel.

Jeśli dwie kolumny mają tę samą nazwę w obu tabelach (konwencja nr 2), możesz użyć składni USING w SQL, aby zaoszczędzić trochę pisania i schematu:

SELECT name, address, amount
  FROM employees JOIN payroll USING (employee_id)

Kolejnym argumentem przemawiającym za konwencją nr 2 jest to, że w ten sposób zaprojektowano model relacyjny .

Znaczenie każdej kolumny jest częściowo przekazywane przez oznaczenie jej nazwą odpowiedniej domeny.

Myślę, że to zależy od tego, w jaki sposób złożysz wniosek. Jeśli używasz ORM lub projektujesz swoje tabele do reprezentowania obiektów, opcja 1 może być dla Ciebie.

Lubię kodować bazę danych jako własną warstwę. Kontroluję wszystko, a aplikacja po prostu wywołuje procedury składowane. Dobrze jest mieć zestawy wyników z pełnymi nazwami kolumn, zwłaszcza gdy jest wiele połączonych tabel i zwróconych wiele kolumn. W przypadku tego rodzaju aplikacji podoba mi się opcja 2. Bardzo lubię, gdy nazwy kolumn pasują do złączeń. Pracowałem na starych systemach, w których nie pasowały i był to koszmar,

Żadna konwencja nie działa we wszystkich przypadkach, więc po co w ogóle ją mieć? Użyj rozumu...

np. w przypadku tabeli odwołującej się do siebie, gdy istnieje więcej niż jedna kolumna FK, która odwołuje się do PK tej samej tabeli, MUSISZ naruszyć oba "standardy", ponieważ dwie kolumny FK nie mogą być nazwane tak samo ... np. , EmployeeTable z EmployeeId PK, SupervisorId FK, MentorId Fk, PartnerId FK, ...

Zgadzam się, że nie ma między nimi wyboru. Dla mnie o wiele ważniejszą rzeczą w przypadku obu standardów jest część „standardowa”.

Jeśli ludzie zaczną „robić swoje”, powinni zostać związani przez swoich netherów. MOIM ZDANIEM :)

Czy rozważałeś następujące kwestie?

Primary Table (Employee)   
Primary Key is PK_Employee

Foreign table (Event)  
Foreign key is called FK_Employee

Konwencja, której używamy w pracy, jest bardzo zbliżona do A, z wyjątkiem tego, że nazywamy tabele w liczbie mnogiej (tj. „Pracownicy”) i używamy podkreślenia między tabelą a nazwą kolumny. Zaletą tego jest to, że aby odwołać się do kolumny, należy podać albo „identyfikator_pracowników”, albo „id.pracowników”, w zależności od tego, jak chcesz uzyskać do niej dostęp. Jeśli musisz określić, z której tabeli pochodzi kolumna, „ID pracowników.pracowników” jest zdecydowanie zbędne.

Jeśli patrzysz na kod aplikacji, a nie tylko zapytania do bazy danych, niektóre rzeczy wydają mi się jasne:

1. Definicje tabel zwykle odwzorowują bezpośrednio klasę opisującą jeden obiekt, więc powinny być pojedyncze. Aby opisać zbiór obiektu, zwykle dodaję „Array”, „List” lub „Collection” do nazwy w liczbie pojedynczej, ponieważ to wyraźniej niż użycie liczby mnogiej wskazuje nie tylko, że jest to zbiór, ale także jakiego rodzaju jest to zbiór to jest. W tym widoku widzę nazwę tabeli nie jako nazwę kolekcji, ale nazwę typu obiektu, którego jest ona zbiorem. Administrator DBA, który nie pisze kodu aplikacji, może przeoczyć ten punkt.

2. Dane, z którymi mam do czynienia, często używają „ID” do celów identyfikacji innych niż kluczowe. Aby wyeliminować pomyłki między kluczami „ID” i „identyfikatorami” niebędącymi kluczami, jako nazwy klucza podstawowego używamy „Klucz” (tak właśnie jest, prawda?) Poprzedzony nazwą tabeli lub skrótem nazwa tabeli. To prefiksowanie (i zastrzegam to tylko dla klucza podstawowego) sprawia, że ​​nazwa klucza jest unikalna, co jest szczególnie ważne, ponieważ używamy nazw zmiennych, które są takie same jak nazwy kolumn bazy danych, a większość klas ma rodzica, identyfikowanego przez nazwę klucz nadrzędny. Jest to również konieczne, aby upewnić się, że nie jest to zastrzeżone słowo kluczowe, którym jest sam „Klucz”. Aby ułatwić zachowanie spójności nazw kluczowych zmiennych i zapewnić programy, które wykonują łączenia naturalne, Klucze obce mają taką samą nazwę, jaka jest używana w tabeli, w której są kluczem podstawowym. Nieraz spotkałem się z programami, które działają znacznie lepiej w ten sposób, używając łączeń naturalnych. W tej ostatniej kwestii przyznaję się do problemu z tabelami odwołującymi się do samych siebie, z których korzystałem. W tym przypadku zrobiłbym wyjątek od reguły nazewnictwa kluczy obcych. Na przykład użyłbym ManagerKey jako klucza obcego w tabeli Employee, aby wskazać inny rekord w tej tabeli.

Podoba mi się konwencja nr 2 - badając ten temat i znajdując to pytanie przed wysłaniem własnego, natknąłem się na problem, w którym:

Wybieram * z tabeli z dużą liczbą kolumn i łączę ją z drugą tabelą, która podobnie ma dużą liczbę kolumn. Obie tabele mają kolumnę „id” jako klucz podstawowy, co oznacza, że ​​muszę specjalnie wybrać każdą kolumnę (o ile wiem), aby te dwie wartości były unikalne w wyniku, tj .:

SELECT table1.id AS parent_id, table2.id AS child_id

Chociaż użycie konwencji nr 2 oznacza, że ​​nadal będę mieć w wyniku kilka kolumn o tej samej nazwie, mogę teraz określić, którego identyfikatora potrzebuję (rodzic lub dziecko) i, jak zasugerował Steven Huwig, USINGstwierdzenie to jeszcze bardziej upraszcza sprawę .

Zawsze używałem userId jako PK na jednej tabeli i userId na innej tabeli jako FK. Poważnie myślę o używaniu userIdPK i userIdFK jako nazw identyfikujących je od siebie. Pomoże mi to szybko zidentyfikować PK i FK podczas patrzenia na tabele i wygląda na to, że wyczyści kod podczas używania PHP / SQL do dostępu do danych, ułatwiając zrozumienie. Zwłaszcza, gdy ktoś inny patrzy na mój kod.

Używam konwencji nr 2. Pracuję teraz ze starszym modelem danych, w którym nie wiem, co oznacza w danej tabeli. Jaka szkoda bycia gadatliwym?

Co powiesz na nazwanie klucza obcego

role_id

gdzie rola jest rolą, którą odwołuje się podmiot do danej tabeli. Rozwiązuje to problem rekursywnych odwołań i wielu fks do tej samej tabeli.

W wielu przypadkach będzie identyczna z nazwą tabeli, do której się odwołuje. W takim przypadku staje się identyczny z jedną z twoich propozycji.

W każdym razie długie kłótnie to zły pomysł

"Gdzie w" zamówieniu WEWNĘTRZNY DOŁĄCZ pracownika NA order.employee_id = worker.id "czy jest potrzeba dodatkowych kwalifikacji?".

Dodatkowe kwalifikacje nie są potrzebne, ponieważ kwalifikacje, o których mówiłem, już istnieją.

„powodem, dla którego użytkownik biznesowy odwołuje się do identyfikatora zamówienia lub identyfikatora pracownika, jest zapewnienie kontekstu, ale na poziomie bazy danych masz już kontekst, ponieważ odwołujesz się do tabeli”.

Módlcie się, powiedzcie mi, jeśli kolumna nosi nazwę „ID”, to jak dokładnie można to zrobić „odwoływanie się [sic] do tabeli”, chyba że poprzez zakwalifikowanie tego odniesienia do kolumny ID dokładnie w sposób, o którym mówiłem?