!FrAgile Thinking

Derik Whittaker na swoim blogu poruszył bardzo ważną kwestię związaną z nadużywaniem procedur składowanych w celu pisania logiki biznesowej. Jako, że należę do zwolenników programowania obiektowego, całkowicie się zgadzam ze zdaniem Derika. W moim ówczesnym jak i w wcześniejszych projektach, często spotykałem się z nadużyciem procedur składowanych do pisania logiki biznesowej, dlatego też jestem świadomy wielu wad takiego podejścia. Podobnie jak Derrik Whittaker, napotkałem się z argumentacją, że procedurę składowaną można szybko zastąpić bez zbędnego ponownego „deployowania” aplikacji. Moim zdaniem nigdy nie powinno dojść do takiej sytuacji dlatego, że podmienianie funkcjonalności „na żywca” wiąże się ze zbyt wielkim ryzykiem. Jaką możemy mieć pewność, że dana zmiana będzie działać? Sytuacje takie najczęściej kojarzą mi się ze scenami z filmów, w których główny bohater przecina kabelki bomby. W rzeczywistości nie jest tak jak w filmach, gdzie wszystko się kończy szczęśliwie z amerykańską flagą w tle:).

Uważam, że częstym powodem podmiany procedur składowanych na środowisku produkcyjnej jest metodologia FDD(Fear Driven Development), w której każdy się boi cokolwiek ruszyć, dlatego, że szybko może doprowadzić to do „wybuchu”. W związku z tym ponowne deployowanie aplikacji z poprawionym błędem wydaje się większym ryzykiem niż podmiana procedury. Najszybszym rozwiązaniem tego rodzaju problemów jest stworzenie skryptów pozwalających zautomatyzować całkowicie proces deploymentu. Jeżeli posiadacie w projekcie dokument z listą koniecznych kroków, do której sięgacie przy każdym deploymencie, to jest to pierwszy poważny znak na to, że nadszedł czas na poprawienie lub stworzenia skryptów. Same skrypty to tylko początek sukcesu. Kolejnym ważnym elementem są automatyczne testy, które muszą się poprawnie wykonać zanim aplikacja zostanie zdeployowana. Zakładając, że dany projekt korzysta z serwera Continues Integration, tego rodzaju zapewnienie nie stwarza żadnego problemu.

Kolejnym argumentem często używanym przez zwolenników procedur składowanych jest wydajność. Trudno czasami zaprzeczyć temu faktowi, dlatego, że wywołanie jednej procedury zawierającej obszerną logikę biznesową to wyłącznie tylko jedno zdalne zapytanie, które musi dokonać nasza aplikacja. W przypadku zaś, gdy nasza operacja biznesowa dokonywana będzie po stronie aplikacji i wymagać będzie ona stworzenia wielu obiektów zapisywanych w bazie danych, jesteśmy zmuszeni do wielu zdalnych zapytań, a to prowadzi z kolei do problemów wydajnościowych. Dlatego też warto skorzystać z dostępnych mapperów obiektowo relacyjnych, z których niektóre są w stanie wywołać wiele kwerend w ramach jednego zapytania (operacje wsadowe). Należy zwrócić uwagę, że to rozwiązanie nie jest złotym środkiem na wszystko. Jednym z przypadków nadużycia jest tworzenie procesu ETL (Extract Transform Load) przy wykorzystaniu mappera dlatego, że wydajność będzie znikoma w porównaniu do wykorzystywania procedur składowanych lub narzędzi przewidzianych do tego rodzaju procesów takich jak na przykład SSIS, a w przypadku tego typu procesów wydajność odgrywa bardzo ważną rolę.

Jeżeli piszecie logikę w procedurach składowanych i dla operacji  innych niż wsadowych ponieważ uważacie, że jest to bardziej wydajne rozwiązanie, zadajcie sobie proste pytanie: Jak często dokonujemy zmian w kodzie? Często jest tak, że zmieniają się wymagania biznesowe, w takich przypadkach klient oczekuje by dana funkcjonalność została jak najszybciej zmieniona i mu udostępniona. Wydajność w tym momencie nie jest kluczowym elementem. Zresztą moim zdaniem często wydajność w aplikacjach biznesowych jest ważna tylko w przypadku, gdy już natrafiamy na problemy z jej brakiem, wówczas to jesteśmy zmuszeni do zlokalizowania wąskiego gardło.

Powracając do problemu ze zmianami. Jak sama nazwa wskazuje procedury składowane są pisane w postaci kodu proceduralnego, co niesie ze sobą wiele ograniczeń w przypadku realizacji zaawansowanej logiki. W dzisiejszych czasach if i else nie wystarcza, dlatego też stosujemy języki obiektowe. Moim zdaniem brak możliwości programowania obiektowego w procedurach składowanych wskazuje na to, że twórcy języka SQL nie mieli zamiaru by język ten służył do programowania skomplikowanej logiki. Poza tym, który z Was jest wstanie zrozumieć w ciągu 5 min zapytanie z więcej niż pięcioma joinami i pod zapytaniem w warunku? Jak tego rodzaju argumenty nie przemawiają do was, to znaczy, że nigdy nie napotkaliście się na procedurę składowaną, która miała więcej niż 100 linii. Kolejnym dużym problemem jest brak możliwości refaktoryzacji kodu procedur składowanych przy pomocy dostępnych narzędzi developerskich. Nie wspominam już o testach jednostkowych. Choć w tym zakresie pojawiło się parę produktów umożliwiających testowanie, co nie znaczy, że zarządzanie tego typu testami jest proste.

Jednym z ciekawych argumentów, z którymi się również spotkałem była prostota wykorzystywania procedur składowanych do integracji wielu aplikacji. Rozwiązanie to ma na celu wyeliminowanie duplikacji kodu, ale jako, że każda z aplikacji jest tworzona najczęściej przez oddzielne zespoły, rozwiązanie to wręcz prowadzi do tworzenia wielu identycznych procedur. W przypadku, gdy dwie aplikacje będą korzystać z tej samej procedury, jaką mamy pewność, że wszelkiego rodzaju zmiany w procedurze konieczna dla jednej aplikacji nie spowoduje błędu w tej drugiej? Każda aplikacja powinna posiadać swój własny ograniczony kontekst, którego nie ma sensu reprodukować w innej aplikacji. Dlatego też nie powinno dochodzić do potrzeby wywoływania tej samej funkcjonalności przez dwie różne aplikacje z poziomu procedury składowanej. Stosowanie współdzielonej bazy danych w dzisiejszych czasach – opanowanych przez architekturę SOA – jest kruche, dlatego warto zastosować integrację na poziomie funkcyjnym.

Mam nadzieję, że argumenty te przekonały Was do rozważnego zastanowienia się nad tym, czy procedura składowana jest odpowiednim rozwiązaniem na Wasze potrzeby, zanim ją użyjecie. Zachęcam również do wyrażenie swojego zdania na ten temat.