@WolandWspanialy zakładam, że mamy jakiś driver abstrakcji w stylu JDBC/ODBC i nie klepiemy binarnej komunikacji z bazą. Nie mamy tylko frameworka, który zamienia wywołań metod na zapytania sqlowe on-the-fly. To nie jest na tyle duży narzut, żeby się nim przejmować.
W korpo praktyce, często zaawansowane rzeczy opakowywało się w procedurę bazodanową, a do zrobienia dawało ludziom, którzy tą bazę utrzymują. Oni sobie klepią, żeby było im wydajnie, a ty masz elegancki interfejs. Oczywiście z podejściem scrumowym średnio się to spina, ale to już problem menadżerów.
@WolandWspanialy
@Vuaaas
Fajny przykład z kariery to pewna firma kurierska, która miała inny silnik bazodanowy w oddziałach, a inny w centrali. Interoperacyjność zapewniało się tak, że struktura widoków i nagłówki procedur były spójne. Inny był tylko środek funkcji, trzeba było napisać dla obu silników oddzielnie. Dodatkowo był tam przedpotopowy postgresql i musiałem się zastanawiać, jak pisać niektóre rzeczy bez window functions.
@Vuaaas Przeczytałem co wkleiłeś. Moim zdaniem chciał sobie popisać to popisał, zgadzam się przede wszystkim że dobierasz technologię do potrzeb użytkownika a nie jest to punkt startu chociaż i tutaj jest wyjątek (patrz niżej)
Mam wystarczająco dużo doświadczenia i udanych optymalizacji żeby uśmiechnąć się pod nosem na sarkazm że dba to wymysł firm tworzących silniki bazodanowe. Moim zdaniem to całkowicie naturalne że programista ma wystarczająco dużo do nauki więc mało który ma wystarczająco dużo czasu na specjalizowanie się w sql, szczególnie w czasach gdy framework robi za Ciebie lwią część roboty w komunikacji z bazą.
I chyba właśnie to najbardziej lubię w mojej pracy. To że pracownik nie musi oglądać kręcącego się kółka ładowania przez 30 sekund tylko przez 3 sekundy. Że jakiś raport który generował się dwa dni i był największym sacrum zespołu zaczyna wykręcać się w pięć minut. Takie małe rzeczy mnie cieszą.
A wracając do dobierania technologii do use case to bardzo często firmy idą w rozwiązania w których mają już specjalistów a nie do każdej aplikacji coś nowego jak fantazja podpowie, tak jest łatwiej zarządzać personelem.
A no i na koniec: Bardzo dobrze że powstał NoSQL, rynek tego potrzebował ale jednak gdzie nie spojrzę to te relacyjne bazy cały czas są (i będą) potrzebne.