Jaki jest skuteczny sposób oznaczania kolumn w bazie danych?

Kiedyś oznaczałem kolumny w moich bazach danych w następujący sposób:

user_id
user_name
user_password_hash

Aby uniknąć konfliktów podczas łączenia dwóch tabel, ale potem dowiedziałem się więcej o tym, jak aliasować tabele, i przestałem to robić.

Jaki jest skuteczny sposób oznaczania kolumn w bazie danych? Czemu?

W twoim przypadku użytkownik prefiksu jest zbędny. My (twórcy) wiemy, że to użytkownik tabeli, więc po co dodawać user_prefiks przed każdym polem?

Sugeruję, abyś zrobił to w bardziej naturalny sposób.

Jakie są cechy charakterystyczne osoby: nazwisko, imię, data urodzenia, obywatelstwo itp.

Jakie są cechy samochodu: model, rok, kolor, energia itp.

Twoja kolumna powinna być nazwana tak naturalnie, jak to możliwe, dzięki czemu schemat będzie bardziej przejrzysty dla wszystkich, dla ciebie i tych, którzy będą po tobie. Nazywa się to również fazą konserwacji i zwykle wszystko, co możesz zrobić, aby ułatwić konserwację, jest warte wysiłku.

Oprócz komentarza Spredzy, oznacz swoje klucze podstawowe tym samym (ID), aby podczas pisania zapytań w locie można było łatwo przywołać (u.ID = c.ID) zamiast konieczności wyszukiwania „Czy to countryID , country_ID, country_ID, countryID,? ”

Nie mogłem się bardziej zgodzić z uzupełnieniem Davida Halla do doskonałej odpowiedzi Spredzy. Prosta i naturalna jest droga. Pomyłka przy stole nie powinna stanowić problemu, jeśli nazywasz także tabele w sposób naturalny.

Nie ma sensu mieć users.user_id i cars.car_id, kiedy można mieć users.id i cars.id

Twierdziłbym, że w schemacie bazy danych każda kolumna powinna mieć unikalną nazwę we wszystkich tabelach. Jest tego kilka przyczyn:

• Z modelowego punktu widzenia: zaczynasz od zupy atrybutów i normalizujesz ją do tabel. Z czasem możesz dalej denormalizować lub normalizować lub wprowadzać widoki lub zmaterializowane widoki lub wprowadzać nowe tabele. Nie stanowi to nigdy problemu, jeśli wszystkie nazwy kolumn są unikalne.

• Możesz użyć tego dołączyć składni: a JOIN b USING (a_id) JOIN c USING (a_id). Bardzo wygodne, a także pomaga w następującym punkcie.

• Jeśli uruchamiasz zapytania z dużą SELECT *liczbą sprzężeń lub tworzysz zmaterializowane widoki , nigdy (cóż, być może rzadko) występuje konflikt. Myśleć o przyłączeniu person.name, product.name, country.nameitp Urgh.

• Ogólnie rzecz biorąc, jeśli masz duże zapytania, trudno jest śledzić, co idoznacza wszędzie.

Zobaczmy, na twoim przykładzie będzie to wyglądać mniej więcej tak:

USERS
----
id
username,
password
registration_date

Używam nazwy tabeli wielkimi literami. To pozwala mi łatwo zidentyfikować tabelę. Kolumny, które właśnie wymieniłem, dotyczą tego, co reprezentują. Staram się nie używać cyfr ani dołączać do nich żadnego prefiksu lub sufiksu. To sprawi, że zapytania będą martwe, proste i całkiem proste.

BTW, myślę, że powinieneś znaleźć jakiś styl, który ci się podoba i trzymać się go. Jeśli często go zmieniasz, będziesz mieć bałaganszy schemat DB.

Podobnie jak inne, zalecam, aby nie dołączać nazwy tabeli jako części kolumny. Chyba, że ​​masz setki tabel z przeważnie podobnymi nazwami kolumn: jeśli masz wiele tuzinów tabel z kolumnami o tytule ID, to z całą pewnością poprzedzaj je nazwą tabeli.

Niedawno opuściłem firmę, w której jeden z programistów wolał prefiksować kolumny klucza podstawowego i klucza obcego pk i fk. Doprowadziło to do niektórych obrzydliwości, w których kolumny zaczynały się od pkfk (zwykle złożony klucz podstawowy oparty na 2 kolumnach, z których jedna kolumna była kluczem obcym do innej tabeli).

Pracuję w środowisku, w którym nazwa każdej kolumny zaczyna się od przedrostka pochodzącego od nazwy tabeli, to nie jest mój wynalazek, ale jestem z niego całkiem zadowolony.

Idealnie nazwy kolumn są unikalne dla wszystkich tabel w bazie danych.

Niektóre spostrzeżenia:

• potrzebujemy tylko aliasów tabel, gdy tabele są łączone wiele razy w instrukcji select
• zapobiega to niektórym błędom podczas kopiowania fragmentów kodu, ponieważ nazwy kolumn muszą być dostosowane do nazwy tabeli
• pomaga pokazać, do której tabeli wskazuje kolumna klucza obcego

Ogólne pomysły: Najważniejsza jest spójność każdej konwencji nazewnictwa: - liczba pojedyncza vs. liczba mnoga (ok, dotyczy to tabel, a nie kolumn) - identyfikacja kluczy głównych i obcych (budują strukturę względem zawartości bazy danych) - być spójna, gdy przechowujesz ciągi i krótki wariant tego samego ciągu - zachowaj spójność z flagami, statusem itp.

Zgadzam się z odpowiedzią Spredzy, ale dodam, że jako preferencję użyłbym camelCase zamiast under_score.

imię, nazwisko itp.

W przypadku Oracle, będziemy chcieli, aby nie nazwać kolumn „id” lub „name” lub coś rodzajowe.

Problem polega na tym, że domyślnie w starszych wersjach Oracle będzie próbować łączyć tabele na podstawie podobnych nazw kolumn, więc jeśli wszystko dobrze nazwałam, to ostatecznie skończyłem też na określeniu domyślnej klauzuli łączenia między moimi tabelami.

Ale nawet jeśli nie używasz Oracle, nie wybierając nazw pojawiających się w wielu tabelach, oznacza to również, że nie musisz wtedy męczyć się z aliasingiem za każdym razem, gdy musisz dokonać wyboru w dwóch tabelach:

SELECT
  instrument.name as instrument_name,
  instrument.abbr as instrument_abbr,
  source.name     as source_name,
  source.abbr     as source_abbr,
  ...
FROM ...

Jeśli więc wybór wielu tabel jest normą, dłuższe nazwy kolumn oszczędzają pisanie. (jeśli używasz tylko jednej tabeli na raz ... czy naprawdę potrzebujesz relacyjnej bazy danych?)

... a oszczędzanie na pisaniu prowadzi nas do kolejnego problemu w Oracle - przynajmniej w 8i (obecna wersja, kiedy wziąłem kursy Oracle SQL Tuning i Data Modeling) buforowanie planów wykonania opiera się tylko na pierwszych tak wielu znakach zapytanie (nie pamiętasz dokładnej wartości ... 1024?), więc jeśli masz zapytania, które różnią się tylko czymś na końcu klauzuli where i naprawdę długą listę wyodrębnianych kolumn, możesz może trafić w wydajność, ponieważ nie może poprawnie buforować planu wykonania.

Oracle miał przewodnik na temat wybierania, jak twierdzą, dobrych nazw tabel i kolumn, co jest w zasadzie przewodnikiem usuwania liter, dopóki nie zawierają około 5-8 znaków, ale nigdy tak bardzo mi na tym nie zależało.

...

Gdy sprawy potoczą się inaczej:

• kolumny są zawsze pojedyncze (tabele są zawsze w liczbie mnogiej)
• wszystkie nazwy są pisane małymi literami, na wypadek, gdyby było w nich rozróżniana wielkość liter
• w wyniku powyższego użyj podkreślników zamiast wielbłąda.

aktualizacja : dla tych, którzy nie są zaznajomieni z zachowaniem łączenia Oracle, zobacz ostatni przykład Mastering Oracle SQL: Join Warunki , w którym wspomniano:

Co się stało? Powodem jest to, że oprócz dostawcy_id te dwie tabele mają inną parę kolumn o wspólnej nazwie. Ta kolumna to nazwa. Tak więc, gdy poprosisz o naturalne połączenie między dostawcą a tabelami części, połączenie odbywa się nie tylko poprzez zrównanie kolumny dostawca_id dwóch tabel, ale także kolumnę nazwy z dwóch tabel. Ponieważ żadna nazwa dostawcy nie jest taka sama jak nazwa części od tego samego dostawcy, zapytanie nie zwraca żadnych wierszy.

Zgodnie ze „starą składnią złączenia” (8i i wcześniejsze) „NATURAL JOIN” było domyślnym zachowaniem łączenia i uważam, że nadal tak jest, jeśli nie określisz warunku łączenia. Kiedyś „NATURAL JOIN” było oficjalną opcją w 9i, ogólną rekomendacją było, aby jej nie używać , ponieważ złe nazewnictwo kolumn może cię zepsuć, co jest moim zaleceniem dla dobrych nazw kolumn.

1. Nigdy nie używaj podwójnych cudzysłowów, "ponieważ w ten sposób zastępujesz natywne składanie baz danych w bazie danych. Specyfikacja SQL wymaga, aby wszystkie identyfikatory były złożone na wielkie litery. Niektóre bazy danych, takie jak PostgreSQL, składają je na małe litery. Jeśli nic nie jest cytowane, będzie działać we wszystkich bazach danych i mogą je złożyć do specyfikacji lub wartości domyślnej specyficznej dla rdbms.
2. Użyj under_score ( _), ponieważ jak wyżej - nie powinieneś używać camelCase.

3. użyj {entity}_iddla identyfikatorów (i kluczy obcych wskazujących na te identyfikatory). Ponieważ wtedy możesz użyć USINGklauzuli. Unikatowe na całym świecie nazwy kluczy używane w warunkach łączenia są konwencją ustanowioną w specyfikacji.

   SELECT *
   FROM employee
   INNER JOIN department
     USING (department_id);
   
     -- compare to
     ON employee.department_id = department.department_id;