Tworzenie SOA opartego o wspólną baze danych jest moim zdaniem jednym z największych anty wzorców, który prowadzi do jednego wielkiego tzw “Big Bull of Mud”, w którym nie tylko logika (zachowanie) jest “pokręcona”, ale również dane. Spowodowane jest to głównie tym, że różne aplikacje korzystają z tych samych danych w różnym kontekście operacyjnym, co skolei eliminuje możliwość stworzenie wspólnego współdzielonego modelu.

W wątku dotyczącym testowania wskazujesz na rozwiązanie, które moim zdaniem jest tylko zaślepką na kolejny poważny problem, czyli brak automatyzacji testów i brak buildu integrującego. O tym problemie wspominałem już wcześniej. Powracając do twoich argumentów, to chętnie bym się dowiedział skąd masz pewność, że zmiana w jednej procedurze składowanej czy trigerzenie nie może wpływać na inne funkcjonalności całego systemu.

Odnośnie piątego argumentu. Moim zdaniem procedura składowana nie jest gwarantem wydajności. Owszem zgodze się z tobą, że w przypadku wywoływania tzw. jobów możemy zyskać na wydajności ze względu na minimalizację zdalnych zapytań do bazy. W systemach informatycznych przewyższa jednak liczba operacji składających się z pojedynczej transakcji wywołanych przez użytkowników systemu, typu złożenie zamówienia. W tym przypadku liczba zdalnych zapytań jest znikoma i już nie uzyskamy zbyt wielkiego wzrostu wydajności, stosując procedurę składowaną.

@Marian Boczek

Jeżeli jesteś zadowolony z procedur składowanych i nie przeszkadzają ci w codziennej pracy to używaj ich dalej. W innym przypadku rozważ sens wyżej przedstawionych argumentów.

Ja sam swego czasu korzystałem nagminnie z procedur składowanych i myślałem, że jest to super wydajne, elastyczne itd. Dzisiaj jak widać już tak nie jest

commit work;
end foreach
Problem w tym, że w klasycznym NHibernate mogę zrobić tylko coś takiego:
foreach (Account account in Criteria.List())
– co zabija serwer, bo cała lista rachunków (milion) jest wczytywana do pamięci
albo: Interfejs Enumerable, który przetwarza wprawdzie po jednym rekordzie, ale dla każdego rachunku wykonuje dodatkowy pojedyńczy select. A jest jeszcze transakcja w środku pętli, czyli coomit zamknie kursor po stronie bazy.
ORM nigdy nie będzie rozwiązaniem wydajnym, bo nie działa na zbiorach, np. takie coś w procedurach końca roku:
update rachunki
set odsetki_rok_poprzedni = odsetki_aktualne,
odsetki_aktualne=0
znów zabija ORM’a, bo każdy rachunek zostanie pojedyńczo pobrany z bazy, a potem zapisany.

Tak więc ORM jest dobry dla obsługi niewielkiej liczby obiektów, typowo w aplikacjach webowych. Ułatwia też tworzenie testów jednostkowych (ale to tylko część, i to ta najprostsza całego procesu testowania). Pozwala uniknąć „SQLi w długich stringach”, jednak to ostatnie zapewniają również SP (są tylko „krótkie stringi”, a liczba odwołań do bazy mniejsza).

Wiem, że jestem na wymarciu, pocieszam się że wciąż jednak istnieje mniejszość w IT, która nie może, lub nie chce nawrócić się na rozwiązania czysto obiektowe (o jej istnieniu świadczą artykuły takie jak „A Database-centric Approach to J2EE Application Development”).

PS: Automatyczne testowanie bazy jest mało wydajne i problematyczne jest przygotowywanie danych potrzebnych do poprawnego wykonania się testu. Co w głównej mierze zniechęca mnie do używania narzędzi typu Team Edition for DB. Co nie znaczy, że w niektórych przypadkach nie należy tego typu rozwiązania używać. Lepiej wolne testy niż żadne