Temat: Antywzorce programisty baz danych
Kiedyś miałem za zadanie poprawić działanie prostego serwisu napisanego w php. Człowiek, który napisał ten serwis nie zadał sobie trudu by przeczytać cokolwiek o projektowaniu baz danych i zupełnie olał pola typu primary key (id)! Rekordy były identyfikowana np. po tytułach, krótkich opisach itp. O kluczach obcych oczywiście nie było mowy.. ;)
Wracają do meritum.
Skupię się nieco bardziej na projektowaniu bazy danych, bo z reguły używam ORM-ów (phpDoctrine, Actice Record, Zend_DB):
1/ Jednym z antywzorców w bazach danych może być zbyt częste zakładanie indeksów, przez co pliki z indeksami mogą być większe od plików z danymi.
2/ Nadmierna normalizacja bazy danych, która może spowodować spadek wydajności. Np. czasami warto przechowywać licznik powiązanych rekordów -
http://railscasts.com/episodes/23
3/ Kwestia zapytań do bazy - nie zawsze warto wyciągać wszystko w jednym zapytaniu. Czasami warto jest duże zapytanie rozbić na kilka mniejszych zapytań. Niestety nie wiem kiedy dokładnie należy stosować tę technikę (obiło mi się coś o uszy zapytaniach skorelowanych i nieskorelowanych) - może mnie ktoś oświeci? :)
4/ To będzie chyba najbardziej dyskusyjna kwestia.. Programując w Ruby On Rails zauważyłem, że istnieje tam tendencja do zwalania roboty, którą może wykonać baza na ORM (Active Record) - np. klucze obce, usuwania kaskadowe itp. Oczywiście ma to swoją wielką zaletę - łatwość migracji na inną wersję bazy danych, ale zapewne niekorzystnie wpływa na wydajność całej aplikacj. Podobne mankamenty można znaleźć w innych frameworkach i ORM-ach.
5/ Antywzorcem może też być odbiegające od wszelkich standardów nazewnictwo tabel i kolumn.
пропозиції роботи
