Wygrać ze złożonością – nazewnictwo obiektów.

Standardy kodowania, dobre praktyki nazewnictwa zmiennych mają na celu zwiększenie przejrzystości kodu, ułatwienie analizę, zminimalizowanie wystąpienia prostych i niepotrzebnych błędów w kodzie. Argumenty te wydają się słuszne i zrozumiałe.

Ale czemu miałoby służyć ustalenie standardów nazewnictwa obiektów bazodanowych?

Powodów usystematyzowania nazw obiektów bazodanowych jest co najmniej kilka.

Czasy „starożytne”
Jednym z historycznych już jak myślę powodów dodawania sufiksów w nazwach obiektów był sposób wersjonowania. Nie było wtedy dedykowanych narzędzi do archiwizowania i wersjonowania skryptów bazy danych. Programiści przechowywali skrypty jako pliki płaskie w zwykłych folderach na dysku. Prefiksy ułatwiały poruszanie się po plikach i znajdywanie skryptów tworzących określone typu obiektów.

Unikalność obiektu
Drugim bardzo istotnym argumentem za stosowaniem standardów nazewniczych jest brak możliwości utworzenia dwóch obiektów o tej samej nazwie w bazie danych, nawet jeśli są innego typu. Prefiksy minimalizują ryzyko wystąpienia błędów tego typu.

Jak tworzyć prefiksy
Podstawowe prefiksy nazewnicze obiektów nie muszą być specjalnie wymyślne. Wystarczy by jasno określały typ danego obiektu. Tak naprawdę najważniejsze w nazwie obiektu, tak jak i w nazwach zmiennych w kodzie jest to, by jasno i precyzyjnie określały przeznaczenie czy funkcję danego obiektu. Nazwa obiektu nie może przekraczać 30 znaków. Dlatego też sam prefiks nie powinien być długi. Wystarczy 2-3 literowy. Ważne, by pozostałe litery dobrze wykorzystać na znaczącą część nazwy obiektu. Szczególnie jest to istotne w nazwach tabel. Po latach nie będziemy pamiętać co oznacz skrót w nazwie tabeli „eas” - lepiej zastosować nazwę znaczącą emp_average_salary.


Przykładowe standardy:

_idx	Index zwykły
_fk	constraint typu klucz obcy
_pkg	Pakiet
_trg	Trigger
_chk	Constraint typu check
_tbs	tablespace

Pewnie wnikliwy programista od razu zauważy brak tabel oraz funkcji i procedur. Brak umieszczenia funkcji i procedur w powyższej tabeli wynika z faktu, że w zasadzie powinno się unikać bezpańskich, wolno-stojących procedur i funkcji. Dobrym nawykiem jest opakowywanie wszystkich procedur i funkcji w pakiety.

Jeśli chodzi zaś o tabele – zastosowanie standardów może nam przynieść o wiele większe korzyści niż informacja, że tabela jest tabelą. Tabele są najbardziej podstawowymi obiektami w bazie danych i najczęściej używane. Każda inforacja „wyciśnięta” z nazwy zwięszka czytelność kodu i ułatwia analizę.

Prefiks czy suffix?
W nazwach obiektów typu index czy trigger najważniejsze jest, jakiej dany obiekt dotyczy tabeli. A że ludzie w większości w Europie czytają z lewej do prawej – zasadne jest umieszanie kluczowych informacji też w tej kolejności. Najpier więc powinniśmy w nazwie obieku zawrzeć informacje najważniejsze czy alias nazwy tabeli a dopiero dalej idąc od lewej – opisać obiekt miarę potrzeb a na końcu oznaczyć jego typ np. -TRG, _IDX, _FK.

Nazwa obiektu
Nazwa obiektu jak wspomnieliśmy nie może mieć więcej niż 30 znaków. Nazwa powinna być znacząca. Ale w przypadku obiektów typu index czy trigger oprócz funckjonalności istotne jest, jakiej tabeli dany obiekt dotyczy. Dlatego standard budowy nazwy obiektu powinien wziąć tę zmienną pod uwagę.

Przykadowo nazwę triggera możemy zbudować z pomocą poniższego wzoru

<alias tabeli>_<nazwa funckjonalna>_<BEF/AFT>_<U/I/D>_TRG

Prefixy i sufixy w nazwach tabel
Nazwy tabel możemy zaprząc do kodowania informacji o zawartości tabeli, o typie danych jakie dana tabela przechowuje.

Jednym z dobrych pomysłów jest określanie w nazwie typu danych przetrzymywanych w tabeli. Podstawowe zbiory danych  to tabele słownikowe, konfiguracyjne, dane i logi. Prefix oznaczający typ obiektu, czyli tabelę, nie będzie tutaj potrzebny. Ponieważ wszystkie pozostałe obiekty będą miały prefix – będziemy mogli przez brak prefixu określajacego typ obiektu zorientować się, że naszym obiektem jest tabela. Dodatkowo prefix typowy dla tabel uszczegółowi nam, z jaką konkretnie tabelą mamy do czynienia:

Przykładowe prefixy:

Słowniki	DICT_
Parametry	PAR_ lub _PAR
Dane	DATA_ lub nic
Logi	<nazwa tabeli głównej>_LOG

Dzięki zastosowaniu prefixu uzyskujemy dodatkową korzyść - tabele tego samego typu będą w narzędziach IDE prezentowane koło siebie.

Jeśli mamy skomplikowany system można zmodyfikować prefixy do własnych potrzeb. W systemie z ogromną ilością tabel dobrze jest na przykład za pomocą prefixu określać też obiekt/funkcjonalność, jakiej dotyczy dana tabela. Na przykład tabela dotycząca samochodów może zaczynać się od prefixu CAR_ itp.

Można połączyć oba stanadardy i stosować podwójne prefixy np.
DICT_CAR_nazwa
DATA_CAR_nazwa

Jednak w takim przypadku należy się zastanowić, czy w takiej sytuacji zamiast dodawania prefiksów funkcjonalnych – nie lepiej utworzyć nowy schemat bazodanowy i przenieść całą funkcjonalność. Mniejsze bazy pogrupowane funkcjonalnie są bardziej przejrzyste i czytelne, łatwiejsze do zarządzania, utrzymania i modyfikacji.

Zadanie standardów
Jedno o czym należy pamiętać: najważniejsza jest przejrzysta i czytelna nazwa. Prefixy mają pomóc uporządkować tabele, ułatwić poruszanie się po skomplikowanym systemie, pomóc w jego analizie i zrozumieniu. Jeśli prefixy nie przynoszą takich korzyści może warto usiąść i ustalić, jakie dane w systemie na którym pracujemy by się przydały do szybciej analizy czy łatwiejszym poruszaniu się po aplikacji?

Podsumowanie:
1. Prefixy powinny zapewniać unikalność obiektu w bazie danych
2. Najważniejsza jest nazwa obiekt – powinna jasno określać zadanie/funckjonalność obiektu
3. W nazwach tabel warto zakodować informacje o typie danych przechowywanych w danej tabeli: słownik, dane, parametryzacja, log
4. W dużych, skomplikowanych systemach można zastanowić się nad użytecznością prefixu określającego obiekt/funckjonalość grupy tabel np. EMP_ - dotyczące pracowników.
5. konwencje 3 i 4 warto połączyć i stosować razem

Przydatne artykuły:
1. Best practices-wygrać ze złożonością, nazewnictwo zmiennych
2. Best Practices - projekt aplikacji a rodzaje zbiorów danych