@globalbus Myślę że te frameworki zdejmują jednak ogrom pracy żeby sobie zapisać lub wyciągnąć obiekt z bazy więc nie wiem czy to wydajne podejście klepać wszystko z palca.

A co do bardziej skomplikowanych sql to powiem szczerze że nie spotkałem wielu programistów którzy by to robili dobrze. Niestety ale jest to dość skomplikowane a nikt nie ma czasu się zagłębiać. Z drugiej strony ja mam dzięki temu zajęcie.

@Vuaaas Co do zmiany silnika to jeżeli Twoją aplikację można od tak przenieść Postgres -> Mongo to... znaczy że nie była ona zbyt skomplikowana 😉

@globalbus 

widziałeś, żeby ktokolwiek w biznesowej aplikacji zmieniał backend bazodanowy? To jest nieistniejący problem

Byłem jakiś czas temu na rozmowie gdzie chcieli mi zlecić taki projekt... Wielka firma, setki baz <machajacy_papiez.jpg>

@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.

@globalbus 

zakładam, że mamy jakiś driver abstrakcji w stylu JDBC/ODBC i nie klepiemy binarnej komunikacji z bazą

Ja nawet nie wiem jak się łączyć do bazy bez jdbc/odbc w wersji thin lub thick. To jest wszakże sterownik który zarządza komunikacją.

Bardziej chodziło mi o Hibernejty i inne srejty które tworzą Ci całe sqlki na podstawie klas, obiektów czy jak to tam się nazywa (nie jestem programistą).

W korpo praktyce, często zaawansowane rzeczy opakowywało się w procedurę bazodanową

Różne rzeczy widziałem. Moim zdaniem zupełnie nieopłacalne bo licencje na RDBMS tanie nie są marnujesz cykle CPU na przetwarzanie kodu.

a do zrobienia dawało ludziom, którzy tą bazę utrzymują

Tego akurat nigdzie nie widziałem chociaż takie zapędy są bo "DBA się zna".

Interoperacyjność zapewniało się tak, że struktura widoków i nagłówki procedur były spójne.

Lub robisz jakieś międzymordzie które ma driver do obu silników i przerzuca dane między nimi, różne potrzeby, różne podejścia

@WolandWspanialy narzut rdbms na wywołanie funkcji to ostatnia rzecz, którą obchodzi korpo. Zakładam, że jednak każdego jednego selecta nie opakowujemy, tylko bardziej zaawansowane twory.

A licencjonowanie Oracle zawsze ciekawe, to prawda.

Lub robisz jakieś międzymordzie które ma driver do obu silników i przerzuca dane między nimi

Dblinki owszem, ale w kurierce te bazy nie gadały ze sobą, to był bardzo asynchroniczny wynalazek, jak na wybuch wojny prawie.

@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.

@globalbus 

narzut rdbms na wywołanie funkcji to ostatnia rzecz, którą obchodzi korpo.

Obchodzi przy odpowiedniej skali. Mam doświadczenie z systemem którego był to główny problem.

tak naprawdę czystych relacyjnych to już nie ma.

Brzmi jak tytuł piosenki, w stylu "prawdziwych cyganów już nie ma" 😉

A poważniej też to widzę i dobrze, rynek RDBMS za długo trwał w stagnacji.