Konwencje nazewnictwa dla tabel i kolumn w bazie danych

Question

Możliwe duplikaty:
Database, Table and Column Naming Conventions?

Za każdym razem, kiedy rozpoczyna się nowy projekt, myślę o konwencje nazewnictwa tabeli i kolumn w bazie danych. Który przypadek jest twoją rekomendacją i dlaczego?

Przypadek 1. column_name
Przypadek 2. NazwaKolumny
Przypadek 3. COLUMN_NAME
Case 4. columnName

Answer 1

Powinieneś użyć case # 1, ponieważ nie ma problemów z rozróżnianiem wielkości liter. Również przypadek wielbłąda wysysa akronimy.

columnID 
columnId 
columnIDAlternative 
columnIdAlternative 
RASCScore 
RascScore 

column_id 
column_id_alternative 
rasc_score 

Również spacje między słowami są przyjemniejsze wizualnie niż zagłuszanie wszystkiego razem. Absolutnie warte tego, co odczuwany ból pisania podkreślenia jest. Podkreślenia symulują spacje, a rzeczowniki złożone i wyrażenia zawierają spacje w normalnym, pisanym języku. TheOnlyPeopleToTypeLikeThisMayHaveBeenTheRomans.

Answer 2

Lubię przypadek 2, wartości wydają się wyróżniać mi lepiej. Cokolwiek wybierzesz, zachowaj spójność!

Answer 3

Używam case 2 (ColumnName) - ponieważ podkreślenia to rodzaj bólu.

Podkreślenia są prawidłowe w nazwach indeksów, wyzwalaczach lub innych obiektach, które nie są często wpisywane. Nie umieszczam ich w tabelach, kolumnach, widokach, przechowywanych nazwach procesów, ponieważ są to często używane nazwy, a sięganie po takie podkreślenie może spowolnić działanie, jeśli często go używasz.

Answer 4

Uwielbiam camelCasing (4) Świetna czytelność, brak podkreślenia

Answer 5

zgadzam się z # 2 z dwóch powodów:

1. podkreślenia są ból pisać.
2. Właściwości .Net zazwyczaj są kodowane w ten sposób. To sprawia, że ​​wszystkie twoje nazwy są zgodne - co jest przydatne i pomaga w sytuacjach, w których korzystasz z ORM.

Uważam, że programiści Javy często używają # 4 w swoich klasach. Chciałbym zmienić moją odpowiedź na # 4, jeśli oprogramowanie klienckie jest w Javie.

Answer 6

Niezależnie od tego, co zdecydujesz się wybrać, najważniejsze jest trzymanie się tego, co jest spójne.

Preferuję # 2, ponieważ jest to najbardziej czytelne i jak wspomniano wcześniej podkreślenie jest brzydkie i denerwujące przy pisaniu. # 4 jest drugi najlepszy. # 3 podoba mi się najmniej, zarówno duże, jak i podkreślenie to przesada.

Answer 7

Głosuję na „Niezależnie od tego, który został użyty w poprzednim projekcie” Spójność w tym przypadku jest chyba ważniejsze niż konkretnej ideologii ...

Answer 8

nazwać moje tabele dokładnie tak samo jak ja nazwać przedmioty, które ja zamierzam je stworzyć, aby je zawinąć. Działa to dobrze z nowoczesnymi ORM-ami (obiektowymi mappersami relacyjnymi), ponieważ często mogą one utworzyć model obiektowy na podstawie struktury bazy danych (lub na odwrót).Przyjęta odpowiedź wydaje się umniejszać "ból wpisywania podkreślenia", ale traktuję to poważnie. Cierpię z powodu RSI, szczególnie w moich pinkach, których używam do przytrzymywania klawiszy Shift i Ctrl, robię absolutnie wszystko, co mogę, aby uniknąć niepotrzebnych podkreśleń. Oczywiście dobrą odpowiedzią na ten problem jest zmiana przypisania klucza CapsLock do klawisza Shift lub klawisza podkreślenia. Ale w każdym razie dodam tę odpowiedź do starego pytania, ponieważ nikt nie wspomniał o pracy z ORM. Odkąd większość programowania w .NET, większość moich właściwości ma wielbłądy obudowane, więc nazywam moje kolumny db w przypadku wielbłąda. Nie mam absolutnie żadnego problemu z skrótami do obudowy wielbłąda. Więc robię rzeczy takie jak:

PersonDao.GetIdByName ("Witaj świecie").

Obudowa wielbłąda zdecydowanie denerwuje długie nazwiska ... ale potem unikam długich imion. Zwykle oznacza to, że źle zorganizowałem sprawy. A jeśli stwierdzę, że nie mam, cóż ... w takich przypadkach długie nazwy są tak rzadkie w moim kodzie i sytuacja tak wyjątkowa, że ​​i tak mnie nie spowalnia.

Myślę, że nazewnictwo ma absolutnie ogromne znaczenie. I tak jak niektórzy ludzie mają fetysze XML, inni mają fetysze baz danych. Osobiście lubię korzystać z moich ORMów, aby całkowicie zignorować moją bazę danych (lub w miarę możliwości). Aby to ułatwić, nazywam moje kolumny tak, jak nazywam właściwości w kodzie. Tak więc, ostatecznie, podkreślam nienawiść na bok, używam wszelkich konwencji obowiązujących dla języka, w którym mój kod istnieje.