Nauczono mnie, aby nie używać nazwy Id
kolumny tożsamości w moich tabelach, ale ostatnio i tak używam jej, ponieważ jest ona prosta, krótka i bardzo opisowa na temat tego, czym właściwie są dane.
Widziałem, jak ludzie sugerują prefiks Id
nazwy tabeli, ale wydaje się, że to po prostu więcej pracy dla osoby piszącej zapytania SQL (lub programisty, jeśli używasz ORM jak Entity Framework), szczególnie w przypadku dłuższych nazw tabel, takich jak CustomerProductId
lubAgencyGroupAssignementId
Jeden zewnętrzny dostawca, którego wynajęliśmy, aby stworzyć dla nas coś, faktycznie nazwał wszystkie swoje kolumny tożsamości, Ident
aby ich nie używać Id
. Na początku myślałem, że to zrobili, ponieważ Id
było słowem kluczowym, ale kiedy się temu przyjrzałem, zauważyłem, że Id
nie jest to słowo kluczowe w SQL Server 2005, którego używamy.
Dlaczego więc ludzie nie zalecają używania nazwy Id
dla kolumny tożsamości?
Edycja: Aby wyjaśnić, nie pytam, której konwencji nazewnictwa należy użyć, ani argumentów, aby użyć jednej konwencji nazewnictwa nad drugą. Chcę tylko wiedzieć, dlaczego nie zaleca się używania Id
nazwy kolumny tożsamości.
Jestem pojedynczym programistą, nie dba, a dla mnie baza danych jest tylko miejscem do przechowywania moich danych. Ponieważ zwykle buduję małe aplikacje i zwykle używam ORM do dostępu do danych, wspólna nazwa pola dla pola tożsamości jest znacznie łatwiejsza do pracy. Chcę wiedzieć, czego mi brakuje, i czy istnieją naprawdę dobre powody, abym tego nie robił.
źródło
Odpowiedzi:
Prefiks nazwy tabeli ma bardzo dobre powody.
Rozważać:
Chcemy
DELETE
zTableA
rekordów, które istnieją w obu tabelach. Łatwo zrobimyINNER JOIN
:.... i właśnie wymazaliśmy wszystko
TableA
. Nieumyślnie porównaliśmy identyfikator B z samym sobą - każdy rekord pasował i każdy rekord został usunięty.Jeśli pola zostały nazwane
TableAId
iTableBId
będzie to niemożliwe (Invalid field name TableAid in TableB
).Osobiście nie mam problemu z używaniem nazwy
id
w tabeli, ale naprawdę lepszą praktyką jest przedmowa z nazwą tabeli (lub nazwą encji, jeśliTableA
ludziePeopleId
byliby również w porządku), aby uniknąć przypadkowego porównania z niewłaściwym polem i nadmuchu coś w górze.To również sprawia, że jest bardzo oczywiste, skąd pochodzą pola w długich zapytaniach z dużą liczbą
JOIN
s.źródło
begin transaction
icommit transaction
byłoby lepszą praktyką niż używanie (imo) bardziej nieznośnego schematu nazewnictwaSELECT
się znaleźć moje rekordy przed uruchomieniemDELETE
, a po uruchomieniu instrukcji zawsze sprawdzam, czy liczba wierszy jest zgodna z oczekiwaniami przed zatwierdzeniem.Głównie ma to na celu powstrzymanie obcych kluczy przed ogromnym bólem. Załóżmy, że masz dwie tabele: Customer i CustomerAddress. Kluczem podstawowym dla obu jest kolumna o nazwie id, która jest kolumną tożsamości (int).
Teraz musisz podać identyfikator klienta z CustomerAddress. Oczywiście nie możesz nazwać identyfikatora kolumny, więc idziesz do id_klienta.
Prowadzi to do kilku problemów. Po pierwsze, musisz konsekwentnie pamiętać, kiedy wywołać kolumnę „id”, a kiedy nazwać „ID_użytkownika”. A jeśli to zepsujesz, prowadzi to do drugiego problemu. Jeśli masz duże zapytanie z kilkunastoma złączeniami i nie zwraca ono żadnych danych, baw się dobrze grając w Where's Waldo i wyszukując tę literówkę:
Ups, powinno być
ON c.id = ca.customer_id
. Lub jeszcze lepiej, nazwij kolumny tożsamości opisowo, aby tak byłoON c.customer_id = ca.customer_id
. Jeśli przypadkowo użyjesz gdzieś niewłaściwego aliasu tabeli, identyfikator_użytkownika nie będzie kolumną w tej tabeli, a otrzymasz ładny błąd kompilacji, zamiast pustych wyników i późniejszego zezowania kodu.To prawda, że są przypadki, w których to nie pomaga, na przykład jeśli potrzebujesz wielu relacji kluczy obcych z jednej tabeli do innej pojedynczej tabeli, ale nazywanie wszystkich kluczy podstawowych „id” też tam nie pomaga.
źródło
Oto podsumowanie wszystkich odpowiedzi na temat korzyści uzyskanych dzięki konwencji, że nie można używać wspólnej nazwy dla wszystkich kluczy podstawowych:
Mniej błędów, ponieważ pola tożsamości nie są nazywane tak samo
Nie można przez pomyłkę napisać zapytania, które łączy się
B.Id = B.Id
zamiastA.Id = B.Id
, ponieważ pola tożsamości nigdy nie będą miały takich samych nazw.Jaśniejsze nazwy kolumn.
Jeśli spojrzysz na kolumnę o nazwie
CustomerId
, natychmiast wiesz, jakie dane są w tej kolumnie. Jeśli nazwa kolumny była czymś ogólnymId
, musisz znać nazwę tabeli, aby wiedzieć, jakie dane zawiera kolumna.Unika niepotrzebnych aliasów kolumn
Możesz teraz pisać
SELECT CustomerId, ProductId
z zapytania, które łączyCustomers
sięProducts
, zamiastSELECT Customer.Id as CustomerId, Products.Id as ProductId
Umożliwia
JOIN..USING
składniMożesz łączyć tabele ze składnią
Customer JOIN Products USING (CustomerId)
zamiastCustomer JOIN Products ON Customer.Id = Products.Id
Klucz jest łatwiejszy do znalezienia podczas wyszukiwania
Jeśli szukasz pola tożsamości klienta w dużym rozwiązaniu, wyszukiwanie
CustomerId
jest o wiele bardziej przydatne niż wyszukiwanieId
Jeśli możesz pomyśleć o innych zaletach tej konwencji nazewnictwa, daj mi znać, a dodam ją do listy.
To, czy zdecydujesz się użyć unikatowych lub identycznych nazw kolumn dla pól tożsamości, zależy od ciebie, ale niezależnie od tego, co wybierzesz, zachowaj spójność :)
źródło
Aby skopiować moją odpowiedź z połączonego pytania:
Jest sytuacja, w której umieszczenie „ID” na każdym stole nie jest najlepszym pomysłem:
USING
słowo kluczowe, jeśli jest obsługiwane. Używamy go często w MySQL.Na przykład, jeśli masz
fooTable
kolumnęfooTableId
ibarTable
klucz obcyfooTableId
, twoje zapytania mogą być skonstruowane jako takie:Nie tylko oszczędza pisania, ale jest znacznie bardziej czytelny w porównaniu do alternatywy:
źródło
Po znormalizowaniu schematu bazy danych w celu ograniczenia redundancji tabele są dzielone na mniejsze tabele o ustalonych relacjach (jeden do jednego, jeden do wielu, wiele do wielu). W tym procesie pojedyncze pola w oryginalnej tabeli mogą pojawiać się w wielu znormalizowanych tabelach.
Na przykład baza danych bloga mogłaby wyglądać tak w nienormalizowanej formie, zakładając unikalne ograniczenie dla nazwy Autor_Nick.
Normalizacja go dałaby dwie tabele:
Autor:
Poczta
W tym przypadku nazwa_nazwa_autora byłaby kluczem podstawowym do tabeli autorów i kluczem obcym w tabeli wpisów. Nawet jeśli nazwa Autor_nazwa pojawia się w dwóch tabelach, nadal odpowiada jednej jednostce informacji, tj. nazwa każdej kolumny odpowiada jednemu polu .
W wielu przypadkach nie może istnieć unikalne ograniczenie oryginalnych pól, dlatego zamiast klucza podstawowego stosuje się sztuczne pole numeryczne. Nie zmienia to faktu, że nazwa każdej kolumny wciąż reprezentuje jedno pole. W tradycyjnym projekcie bazy danych nazwy poszczególnych kolumn odpowiadają pojedynczym polom, nawet jeśli nie są kluczami. (np. należy użyć part.partname i client.clientname zamiast part.name i client.name ). To jest powód istnienia
INNER JOIN ... USING <key>
iNATURAL JOIN
składni.Jednak obecnie, a warstwy ORM są łatwo dostępne w wielu językach, bazy danych są często zaprojektowane jako warstwa utrwalająca dla języków OO, w których naturalne jest, że zmienne, które pełnią tę samą rolę w różnych klasach, nazywane są takimi samymi ( part.name i client.name nie part.partname i client.clientname ). W takim kontekście używam „ID” dla moich kluczy podstawowych.
źródło
Użycie „Ident” zamiast „Id” tak naprawdę niczego nie rozwiązuje, jeśli „Ident” ostatecznie zostanie użyte na wszystkich stołach.
Na stronie Drupal znajduje się dobry artykuł na temat konwencji kodowania SQL, który wskazuje dobrą praktykę w tej sytuacji:
Z tego punktu widzenia sensowne jest użycie CustomerProductId i AgencyGroupAssignmentId. Tak, to dość gadatliwe. Możesz go skrócić, ale najważniejszą rzeczą, na którą należy się wtedy zwrócić, jest to, czy programista, który cię śledzi, zrozumie, co miałeś na myśli . Identyfikatory poprzedzone pełnymi nazwami tabel nie powinny pozostawiać dwuznaczności co do tego, czym są. I (dla mnie) jest to ważniejsze niż zapisanie kilku naciśnięć klawiszy.
źródło
Nazwij moje kolumny CustomerID zamiast ID, więc za każdym razem, gdy piszę
Monit SQL natychmiast sugeruje, co następuje
Oszczędza mi to kilka naciśnięć klawiszy. Uważam jednak, że konwencje nazewnictwa są bardzo subiektywne i jako takie nie mam silnej opinii w ten czy inny sposób.
źródło
Jest to ten sam powód, dla którego nie nazwałbyś wszystkich swoich pól varchar coś w rodzaju „UserText” i „UserText1”, lub dlaczego nie używałbyś „UserDate” i „UserDate1”.
Zazwyczaj, jeśli masz pole tożsamości w tabeli, jest to twój klucz podstawowy. Jak zbudowałbyś tabelę podrzędną z kluczem obcym do tabeli nadrzędnej, gdyby kluczem podstawowym w obu tabelach był identyfikator?
Nie wszyscy zgadzają się z tą metodą, ale w moich bazach danych przypisuję unikalny skrót do każdej tabeli. PK dla tej tabeli nosi nazwę PK_ [abbrv] ID. JEŻELI jest używany jako FK gdziekolwiek, wtedy użyłbym identyfikatora FK_ [abbrv]. Teraz nie zastanawiam się nad tym, jakie są relacje między tabelami.
źródło
Zasadniczo z tego samego powodu, dla którego zwykle nie nazywa się parametrów parametr1, parametr2 ... jest dokładny, ale nie opisowy. Jeśli widzisz TableId, prawdopodobnie możesz bezpiecznie założyć, że jest on używany do przechowywania pk dla Table, niezależnie od kontekstu.
Jeśli chodzi o tego, kto używał Ident, całkowicie nie rozumie sensu, mając wybór między Ident a Id. Ident jest jeszcze bardziej mylący niż Id.
Poza kontekstem można założyć, że Id jest kluczem podstawowym do niektórych tabel (nie jest to szczególnie przydatne, chyba że identyfikator jest przewodnikiem), ale Ident nawet o tym nie mówi (a przynajmniej mnie). W końcu doszłam do wniosku, że Ident jest skrótem od tożsamości (w taki czy inny sposób), ale czas, który spędziłem, zastanawiając się nad tym, byłby zmarnowany.
źródło
Użyj prefiksu, aby ta sama nazwa mogła być używana zarówno w kontekście klucza podstawowego, jak i klucza obcego, abyś mógł wykonać
natural join
/join ... using
.źródło