@Ljopkelsej  Na start jak znalazł

@WolandWspanialy piszę SQLki, bo to szybsze niż zapoznawanie się z kolejnymi abstrakcjami, by nie strzelić sobie w kolano

Poza tym, coś trudniejszego od select * from tabelka join tabelka 2, zwykle i tak pisze się ręcznie.

@globalbus To trochę słabo bo jak będziesz chciał zmienić mysql na postgresa albo co gorsza mongo to chyba szybciej będzie napisać aplikacje od nowa

@Vuaaas widziałeś, żeby ktokolwiek w biznesowej aplikacji zmieniał backend bazodanowy? To jest nieistniejący problem. A działają do dziś takie silniki bazodanowe, o których nawet ciężko coś przeczytać w literaturze, a robi się support dla aplikacji na nich

@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 Tak, widziałem, nawet tak robiłem

@WolandWspanialy Nie trzeba zmieniać całej bazy, wystarczy pojedyncze encje które byłyby bardziej efektywne w bazie dokumentów

@Vuaaas Jestem tu bardziej z kolegą @globalbus. Jeżeli kiedyś tak robiłeś to musiał być to szczególny przypadek.

Jeżeli byłeś na Postgresie to aplikacja zakładała ACID jako fundament. Jak to wydajnie przenieść do Mongo ? Przejście z między dużymi silnikami jak Oracle na MSsql potrafi być bardzo trudne do zamiany ze względu na różnice w zarządzaniu transakcyjnością a co dopiero z Postgres na Mongo.

Pojedyncze Encje - czyli część funkcjonalności przenosisz i robisz środowisko niehomogeniczne ?

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

@globalbus @WolandWspanialy Nie będę się głębiej rozwodzić nad tematem, bo ja jestem bardziej od architektury aplikacji, niż samych baz danych. Jako Ciekawostkę wrzucam jeszcze post który mi się przypomniał czytając komentarze. https://blog.cleancoder.com/uncle-bob/2012/05/15/NODB.html

@Vuaaas tak naprawdę czystych relacyjnych to już nie ma. Spokojnie można sobie trzymać w środku tabel dokumenty jsonowe i traktować je jak nosql. Spatial? Też nie ma problemu. Za to upieranie się, że SQL to zło i najlepiej go nie widzieć, często kończy się tym, że potem patrzę w korpo APMie, jak ktoś robi selecty w pętli.

@WolandWspanialy nie o pozycję programisty chodzi a coś w stylu data analyst w finansowych korpo, wymagają zazwyczaj znajomości SQL i Pythona/R. Nie zamierzam zdobyć wiedzy na poziomie wyroczni tych języków, jedynie taką aby dała mi możliwość zahaczenia się o tego typu pracę. Znudziło mi się to co obecnie klikam w korpo i szukam czegoś innego, bardziej technicznego bo to moja mocna strona, ale nie stricte programowania. Dzięki za rady.

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

@WolandWspanialy

@globalbus Zapomniałem o tym !