Comments on: Konwencja nazewnictwa baz danych

By: Hubert Marzec

Hubert Marzec — Sun, 28 Dec 2008 14:01:34 +0000

@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.

By: esTMan

esTMan — Sat, 27 Dec 2008 23:18:38 +0000

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.!

By: Koziołek

Koziołek — Tue, 02 Sep 2008 22:03:30 +0000

@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.

By: Szymon

Szymon — Wed, 09 Apr 2008 07:53:00 +0000

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).

By: Paweł Krefta

Paweł Krefta — Fri, 28 Mar 2008 23:38:22 +0000

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 :)

By: Hubert Marzec

Hubert Marzec — Fri, 28 Mar 2008 21:31:48 +0000

@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’.

By: kemot_p

kemot_p — Fri, 28 Mar 2008 13:30:58 +0000

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:)