Friday, September 14, 2007

Baza danych.

Baza danych w programie i metody nią zarządzające służą tylko do dostępu do danych. Tylko i wyłącznie.

Nie powinno się w tych częściach aplikacji implementować czegokolwiek innego, w szczególności złymi pomysłami jest wrzucanie tam jakiejkolwiek logiki biznesowej, bezpieczeństwa, czy weryfikacji poprawności danych. Te rzeczy mają miejsce o poziom wyżej.

Pomysł podawania metodzie odczytującej z bazy danych danych użytkownika by ta sobie sama sprawdziła jego przywileje, wydaje sie sensowny.... do momentu w którym chcesz te dane przeczytać w miejscu w którym nie ma użytkownika. Np. podczas nocnej weryfikacji danych z bazy.

Pomysł tego żeby logika biznesowa była w bazie danych też jest poroniony. Jeśli twoja metoda robi coś więcej niż 'zwraca wszystkie dane spełniające dane kryterium', 'zwraca dane o unikalnym id', robi już zbyt dużo. To podejście jest złe na przykład dlatego że zmiany w logice biznesowej wprowadzane na bazę danych są widoczne od razu w całym systemie (i jak developer coś spieprzy, to aplikacja padnie u wszystkich podpiętych do tej bazy).

Pomysł na to żeby dostęp do bazy danych sprawdzał ich poprawność jest fajny jak się o nim myśli. Tylko co baza ma zrobić jak wykryje ową niepoprawność? Rzygnąć wyjątkiem, ot co. Ale kto ten wyjątek złapie? Właśnie często nikt --- czyli złapie go użytkownik.

W jednym projekcie ktoś wpadł na zajebisty pomysł wykonania takiego selecta:
SELECT * FROM umowa WHERE umowaId = id AND cośtam = id2

Dodam że umowaId była już unikalna. AND powodował że jeśli kontrahent był nie ustawiony select zwracał pusty set, a metoda rzygała wyjątkiem. Kiedy pani sbie skasowała kontrahenta wiodącego z umowy, potem oglądała piękny ekran o błędzie. Gdyby nie było tej weryfikacji, pani mogła by sobie tą umowę poprawić ręcznie. A tak musieli to robić developerzy na bazie danych...