Nazewnictwo tabel: podkreślenie czy Camelcase? przestrzenie nazw? Liczba pojedyncza czy mnoga?

Czytałem kilka pytań / odpowiedzi na StackOverflow, próbując znaleźć „najlepszy”, lub powinienem powiedzieć, akceptowany sposób nazwania tabel w bazie danych.

Większość programistów ma tendencję do nazywania tabel w zależności od języka, który wymaga bazy danych (JAVA, .NET, PHP itp.). Jednak po prostu czuję, że to nie w porządku.

Sposób nazywania tabel do tej pory polega na zrobieniu czegoś takiego:

doctorsMain
doctorsProfiles
doctorsPatients
patientsMain
patientsProfiles
patientsAntecedents 

Martwię się o:

• Czytelność
• Szybka identyfikacja modułu, z którego pochodzi tabela (lekarze || pacjenci)
• Łatwe do zrozumienia, aby uniknąć nieporozumień.

Chciałbym zapoznać się z opiniami dotyczącymi konwencji nazewnictwa. Dziękuję Ci.

Konsekwencja jest o wiele ważniejsza niż to, jakiego konkretnego schematu używasz.

Zwykle używam PascalCase, a jednostki są pojedyncze:

DoctorMain
DoctorProfile
DoctorPatient

Naśladuje konwencje nazewnictwa klas w mojej aplikacji, dzięki czemu wszystko jest schludne, czyste, spójne i łatwe do zrozumienia dla każdego.

Charakter obsługi SQL bez rozróżniania wielkości liter Underscores_Scheme. Nowoczesne oprogramowanie obsługuje jednak wszelkiego rodzaju schematy nazewnictwa. Czasami jednak niektóre paskudne błędy, błędy lub czynnik ludzki mogą prowadzić do UPPERCASINGEVERYTHINGtego, że ci, którzy wybrali oba Pascal_Casei Underscore_Caseschemat, żyją ze wszystkimi nerwami w dobrym miejscu.

Agregacja większości z powyższych:

• nie polegaj na wielkości liter w bazie danych
• nie uwzględniaj wielkości liter lub separatora w nazwie - tylko słowa
• używaj dowolnego separatora lub wielkości liter, które są standardem w Twoim języku

Następnie możesz łatwo tłumaczyć (nawet automatycznie) nazwy między środowiskami.

Ale dodałbym jeszcze jedną uwagę: może się okazać, że istnieją inne czynniki, kiedy przechodzisz z klasy w aplikacji do tabeli w bazie danych: obiekt bazy danych ma widoki, wyzwalacze, przechowywane procesy, indeksy, ograniczenia itp. również potrzebują nazw. Na przykład może się okazać, że uzyskujesz dostęp do tabel tylko za pośrednictwem widoków, które zazwyczaj są po prostu prostym „wybierz * z foo”. Można je zidentyfikować jako nazwę tabeli za pomocą tylko przyrostka „_v” lub umieścić je w innym schemacie. Celem takiej prostej warstwy abstrakcji jest to, że w razie potrzeby można ją rozszerzyć, aby umożliwić zmiany w jednym środowisku, aby uniknąć wpływu na inne. To nie zniweczy powyższych sugestii dotyczących nazewnictwa - tylko kilka rzeczy do uwzględnienia.

Używam podkreśleń. Zrobiłem projekt Oracle kilka lat temu i wydawało się, że Oracle wymusiło na wszystkich moich nazwach obiektów pisanie dużymi literami, co niweczy każdy schemat wielkości liter. Nie jestem facetem z Wyroczni, więc może istniał sposób na obejście tego, którego nie byłem świadomy, ale spowodowało to, że użyłem podkreślenia i nigdy nie wróciłem.

Ponieważ pytanie nie jest specyficzne dla konkretnej platformy lub silnika DB, muszę powiedzieć, że dla maksymalnej przenośności należy zawsze używać nazw tabel małymi literami.

/ [a-z _] [a-z0-9 _] * / to naprawdę jedyny wzorzec nazw, który bezproblemowo tłumaczy się między różnymi platformami. Małe litery alfanumeryczne + podkreślenie zawsze będą działać spójnie.

Jak wspomniano w innym miejscu, nazwy relacji (tabel) powinny być podawane w liczbie pojedynczej: http://www.teamten.com/lawrence/programming/use-singular-nouns-for-database-table-names.html

Zwykle zgadzam się z ludźmi, którzy twierdzą, że zależy to od konwencji języka, którego używasz (np. PascalCase dla C # i snake_case dla Ruby).

Jednak nigdy camelCase.

Po przeczytaniu wielu innych opinii myślę, że bardzo ważne jest stosowanie konwencji nazewnictwa języka, spójność jest ważniejsza niż konwencje nazewnictwa tylko wtedy, gdy jesteś (i będziesz) jedynym twórcą aplikacji. Jeśli chcesz mieć czytelność (która ma ogromne znaczenie), lepiej używaj konwencji nazewnictwa dla każdego języka. Na przykład w MySQL nie sugeruję używania CamelCase, ponieważ nie wszystkie platformy uwzględniają wielkość liter. Więc tutaj podkreślenie idzie lepiej.

To moje pięć centów. Doszedłem do wniosku, że jeśli w jednym projekcie są używane bazy danych od różnych dostawców, są dwa najlepsze sposoby:

1. Użyj podkreślenia.
2. Użyj wielbłąda z cytatami.

Powodem jest to, że niektóre bazy danych konwertują wszystkie znaki na wielkie, a inne na małe. Tak więc, jeśli masz myTable, stanie się MYTABLElub mytablebędziesz pracować z DB.

Niestety nie ma „najlepszej” odpowiedzi na to pytanie. Jak stwierdził @David, spójność jest znacznie ważniejsza niż konwencja nazewnictwa.

istnieje duża różnorodność w zakresie oddzielania słów, więc będziesz musiał wybrać to, co lubisz bardziej; ale jednocześnie wydaje się, że istnieje prawie zgoda co do tego, że nazwa tabeli powinna być pojedyncza.

Konwencje nazewnictwa istnieją w zakresie języka, a różne języki mają różne konwencje nazewnictwa.

SQL domyślnie nie rozróżnia wielkości liter; więc snake_case jest powszechnie używaną konwencją. SQL obsługuje również identyfikatory rozdzielane; więc mieszana wielkość liter w opcji, jak camelCase (Java, gdzie pola == kolumny) lub PascalCase (C #, gdzie tabele == klasy i kolumny == pola). Jeśli twój silnik DB nie obsługuje standardu SQL, to jest jego problem. Możesz zdecydować się z tym żyć lub wybrać inny silnik. (A dlaczego C # po prostu musiał być inny, jest irytacją dla tych z nas, którzy kodują w obu).

Jeśli zamierzasz używać tylko jednego języka w swoich usługach i aplikacjach, używaj konwencji tego języka na wszystkich warstwach. W przeciwnym razie użyj najczęściej używanych konwencji języka w domenie, w której ten język jest używany.