Dodaj mój rss to swojego czytnika.
Ludzie tworzą pewne standardy, aby ułatwiać życie sobie i innym. W przypadku języków programowanie java czy php, standardy nazewnictwa i kodowania są jasno zdefiniowane (PEAR2 Standards, Zend Framework Coding standard) i wystarczy ich jedynie przestrzegać. W przypadku baz danych jest już gorzej…
Dlatego też postanowiłem wypracować standard, który będę używał w swoich projektach. Cześć rzeczy może budzić kontrowersje, dlatego bardzo liczę na waszą reakcje. Wpis ma status ‘open’ i na pewno będę wprowadzał do niego zmiany.
Podstawy
- używamy wyłącznie języka angielskiego
- nazwy piszemy małymi literami
- jako separator używamy podkreślenia
- staramy się nie używać cyfr
- używamy krótkich i samo komentujących się nazwy
Tabele
Wydaje mi się, że najbardziej spornym zagadnieniem jest czy nazwy tabel powinniśmy pisać w liczbie mnogiej czy pojedynczej? Osobiście skłaniam się ku pierwszej opcji, czyli mamy tabele: users, orders, tickets. Zaś w kodzie aplikacji, nazwy modeli nazywam w liczbie pojedynczej, np user. Więcej odnośnie tego zagadnienia możecie przeczytać w artykule Plural vs Singular Table Names, polecam również komentarze do tego wpisu.
Problem napotykamy przy tabelach powiązanych. Załóżmy, że mamy tabele events, jeden ewent posiada wiele biletów. Tabele określającą powiązanie one-to-many proponuje nazwać poprzez utworzenie liczby pojedynczej z pierwszej tabeli i dodanie nazwy drugiej: event_tickets. Zaś relacje many-to-many tworzymy poprzez połączenie nazw obu tabel, np. doctors_patients. Podsumowując:
- nazwy tabel są w liczbie mnogiej (np. users, tickets)
- relacje one-to-many w postaci pojedyczna_mnoga
- relacje many-to-many w postaci mnoga_mnoga
Kolumny
Oczywicie unikamy nazw zastrzeżonych dla danych serwerów baz danych. Klucz główny zawsze nazywamy id. Klucze obce tworzymy dodając do nazwy tabeli postfix “id”, np. content.users_id. Kolumny powinny być nazwane w logiczny sposób tak, aby ich nazwy dobrze oddawały naszą intencję. Staramy się być konsekwentni i w różnych tabelach te same pola nazywam tak samo. Jeżeli w jednym projekcie mamy user.first_name to błędem będzie użycie nazwy client.firstname. Dla kolumn logicznych używamy prefixa is lub has, np. is_visible, has_permission. Dla kolumn przechowujących datę używamy postfixa date, otrzymująć start_date, expire_date.
Każdy powinien wypracować swój styl i się go trzymać. Nie da się obiektywnie stwierdzić, który styl jest lepszy, a który gorszy. Najważniejszy aby standard był przestrzegany przez wszystkich członków zespołu, a ci którzy się nie dostosują powinny być karani chłostą :)
Ps. A ty jakie standardy stosujesz?
Friday, March 28, 2008 2:30 pm
Zasadniczo się z Tobą zgadzam. KOntrowersyjne są dla mnie jedynie 2 kwestie: stosowanie języka angielskiego oraz tworzenie kluczy głównych. W przypadku języka służącego do tworzenia nazw tabel, kolumn, widoków itp nie koniecznie musi to być angielski. Moje kilkumiesięczne (może i to mało ale zawsze…) doświadczenie pokazuje, że w wielu przypadkach stosowanie angielskiego znacznie utrudnia sprawę. Dla przykładu tworzymy tabelę firm i zachodzi konieczność przechowywania informacji o numerze rejestru w sądzie rejestrowym. Używając angielskiego trzeba by taką kolumnę nazwać CourtAndCapitalInformation, a po polsku poprostu KRS (od Krajowy Rejestr Sądowy). Oczywiście takie przykłady można mnożyć…
Druga sprawa to klucze główne. Ja osobiście jestem zwolennikiem tworzenia kluczy złożonych z kilku kolumn. Np: mam tabelę produkty i tabelę produkty_rej rejestrującą zmiany na tabeli produkty. Wydaje mi się ze bardziej logiczne jest utworzyć klucz główny w tabeli produkty_rej z dwóch kolumn id oraz produkt_id. Przy takim kluczu wystarczy wyselektować tabelę produkty_rej i bez żadnych obliczeń widać np: ile było zmian na danym towarze. Ja podczas pracy staram się przestrzegać takiej właśnie konwencji:)
Friday, March 28, 2008 10:31 pm
@kemot_p, moim zdaniem twój argument odnośnie używanie języka angielskiego nie jest dobry. Równie dobrze mogę tę kolumnę nazwać cci (CourtAndCapitalInformation). Ty używasz skrótu, co w ogóle nie jest dobrym rozwiązaniem. Z czasem ktoś doda do tabeli kolumny, krp, pks i na pewno nie będzie to czytelne. Już bardziej prawidłowo byłyby nazwać ją krajowy_rejestr_sadowy.
Co do używania złożonych kluczy obcych, to musisz mi wytłumaczyć o co chodzi Ci z “Przy takim kluczu wystarczy wyselektować tabelę produkty_rej i bez żadnych obliczeń widać np: ile było zmian na danym towarze”, bo jeżeli ja Cię dobrze rozumiem, to równie dobrze mogę otrzymać te informacje, kiedy PK będzie się składał tylko z jednej kolumny ‘id’.
Saturday, March 29, 2008 12:38 am
Co do jezyka angielskiego - to zalezy. Mnie polskie nazewnictwo boli. Moze dlatego ze pisze caly kod w jezyku angielskim ? :) Mieszanie dwoch jezykow jest dla mnie czyms nienaturalnym. Co z tego wszystkiego wynika - ze nazwy w bazie tez powinny byc anglojezycznego :) Oczywiscie nie jestem jakos tak superpedantyczny aby pisac takie dziwadla u mnie bylby na 100%.
Co do reszty sie zgadzam - poza liczba mnoga. Zalezy do powaznie od tego jak sie programuje - korzystajac z mapowania czy nie. Liczba mnoga jest dobra jak sie pisze zapytania bo jest czytelniej - temu nie przecze, ale majac ORM - ja takowy posiadam ( samodzielnie napisany ala Django ) tak naprawde nazewnictwo tabel jest malo znaczace bo rzadko tam zagladam. A wtedy liczba pojedyncza ma wielki plus - odpada potrzeba odmieniania. Owszem moznaby definiujac model robic baze odmian ( ja tak czasem robie dla wygody ) ale np CakePHP z tego co pamietam odmienia - a wydajnosci frameworka napewno to nie podnosi - zreszta Cake - to bylo :)
Thursday, September 4, 2008 8:53 am
Zgadzam się z Pawłem. Najgorszą opcją jest mieszanie dwóch języków - albo po polsku albo po angielsku, przy czym oczywiście preferowanym językiem jest ten drugi.
Druga sprawa to właśnie liczba mnoga - osobiście widzę więcej minusów takiego rozwiązania niż plusów, w związku z czym nie jestem jego zwolennikiem. I tutaj ponownie: jakąkolwiek opcje się wybierze, ważne jest aby się jej trzymać cały czas (ewentualnie zmienić przy nowym projekcie - nigdy w trakcie).
Saturday, February 9, 2008 11:03 pm
@kemot_p, język angielski jest standardem w informatyce więc używanie polskiego nie jest dobrym pomysłem. Przykładowa sytuacja, która ma miejsce w mojej firmie. Zespół supportowy otrzymał do wsparcia produkt napisany przez pracowników firmy z Portugalii. Nazwy tabel były po portugalsku w dodatku skrótami. Efekt był taki, że znam kilka podstawowych zwrotów w tym języku.
@Paweł, @Szymon, mając konfigurowalnego ORM można na nim wymusić konwencje nazw, ale to jest zabawa. Liczba mnoga sprawdza się raczej przy nazywaniu zmiennych, gdzie kolekcje nazywasz liczbą mnogą, a elementy pojedynczą lub jedną literą w pętlach.
Sunday, December 28, 2008 12:18 am
Zasadniczo zgadzam się z tym co napisałeś.!! :)
Jednakże bezapelacyjnie do nazywania tabel należy stosować liczby pojedynczej.
Głównie ze względu na klasy ORM, jeżeli używasz Propel-a to będziesz wiedzieć OCB.!
Sunday, December 28, 2008 3:01 pm
@esTMan Używałem Propela przez ponad rok, nienawidzę go! :) Może coś się zmieniło, ale niby dlaczego w Propelu trzeba używać liczby pojedynczej? Przecież tam mamy dwa rodzaje klas, np ‘Users’ i ‘UsersPeer’, równie dobrze może być ‘User’ i ‘UserPeer’. Z tego co pamiętam to Propel nie wymuszał żadnej konwencji nazewnictwa.