Drugie pytanie: jak wytłumaczyć komuś kto ma kilka aplikacji na jednej bazie danych (co raczej nie jest czymś nadzwyczajnym) żeby nie implementował logiki w bazie?
Kilka aplikacji na jednej bazie danych. Bardziej nie da się już zepsuć...
@jarekr000000: Nie można takich rzeczy pisać młodym ludziom, bo się nauczą, że to coś złego. To tak jakby pisać, że kolokacja nie ma sensu, albo że kilka aplikacji na jednym serwerze to zepsute. Szczególnie bez zdefiniowania czym jest owa "jedna baza danych" ;)
Nawet jeśli logika będzie poza bazą danych, to możliwość zmiany tych samych danych przez 2 różne aplikacje (w sensie logicznym, a nie fizyczne instancje), moim zdaniem, już jest bardziej zepsute niż wiele aplikacji korzystających z tego samego serwera bazodanowego i zmieniającego rozłączne dane na różne sposoby (część via PL/SQL, część przez coś innego).
Offtopic:
Jeśli ktoś finansuje aktywności R&D i ma głębokie kieszenie, to może zagwarantować warunki, w których można się skupiać na idealnych rozwiązaniach (kto by nie chciał takiej idealnej roboty, żeby tworzyć doskonałe rozwiązania i poświęcić jeszcze tylko dodatkowy rok na dowiezienie jeszcze lepszego rozwiązania ;-) ) W praktyce jednak inwestorzy (biznes) zakładają jakąś stopę zwrotu (oszczędność lub zysk w określonym horyzoncie czasowym) z inwestycji w automatyzację i szybsze/tańsze rozwiązanie będzie po prostu preferowane. Nawet doczekało się to dedykowanego określenia: Homo oeconomicus. Jeśli ktoś nie zakłada zwrotu w inwestycję, to może optymalizować jakość (pewnie dlatego rozwiązania z tagiem "Open Source" bywają lepsze w wielu obszarach).
@vpiotr: "jak wytłumaczyć komuś kto ma kilka aplikacji na jednej bazie danych (co raczej nie jest czymś nadzwyczajnym) żeby nie implementował logiki w bazie?" - wydaje mi się, że trzeba rozmawiać z tym, kto faktycznie decyduje i za to płaci i mówić do tych osób językiem, który są w stanie zrozumieć :-)
Jak dla mnie można wydzielić 3 warianty:
a) cała logika na bazie
b) rozsmarowana logika (część na bazie, część w aplikacjach)
c) cała logika w aplikacjach
Na to nakładamy dane historyczne w postaci ilości "change requestów", "ilości błędów" spowodowanymi rozsmarowaniem logiki vs. całkowita ilość CRów/ błędów
Na tej podstawie mieć narrację "gdyby logika była w jednym miejscu", to:
- ilość CRów/błędów ze względu na rozsmarowaną logikę byłaby 0 (to biznes może przeliczyć na kasę wydawaną w ciągu roku na obsługę CR/błędów -> oszczędność)
- koszt CRa zaimplementowanego na bazie / aplikacji (optymalizacja developmentu, taniej robić zmiany w miejscu X niż w Y)
Ot można zebrać dane i zbudować jakiś "biznes case" na przepisanie logiki do wybranej technologii i wykazać, że inwestycja zyliona $ zwróciłaby się po 3-5 latach, albo po trylionie lat i nie ma najmniejszego sensu tego robić, tylko dalej opłaca się rozsmarowywać logikę, bo biznes np. zakłada, że co 5-8 lat wymienia systemy.