Nie widzę sensu używania baz SQL

Na wstępnie przyznaję że tytuł specjalnie chwytliwy ;) Oczywiście zdaje sobie sprawę że relacyjne bazy danych mają swoje miejsce, tak jak wszystko w branży. Ale...

Niedługo minie 2 lata od kiedy założyłem wątek pytając o NoSQL. Wtedy mentalnie jeszcze byłem twardo w modelu relacyjnym- z czego zresztą zdawałem sobie sprawę i wspomniałem w tamtym wątku. Przez te 2 lata sporo się zmieniło i miałem dużo styczności z NoSQL- zarówno zawodowo jak i we własnych projektach hobbistycznych. Pomyślałem że podzielę się luźnymi przemyśleniami jak zmieniła się moja perspektywa jeśli chodzi o bazy SQL i NoSQL.

Znów będzie trochę kontrowersyjnie- dziś uważam że bazy SQL nie powinny być domyślnym wyborem. Piszę to przede wszystkim z perspektywy programisty a nie administratora systemu, chociaż i w tym drugim przypadku to wcale nie musi odbiegać od prawdy. Dla czego uważam że nie powinny? Dzięki NoSQL możemy skupiać się na modelowaniu domeny naszej aplikacji i nie przejmować (w granicach rozsądku) "kształtem" obiektów zapisywanych do bazy. Po prostu tworzymy lub aktualizujemy klasę, tworzymy instancję tej klasy i zapisujemy do bazy. Nie trzeba zajmować się tworzeniem skryptów SQL czy migracji jeśli używamy jakiegoś pełnoprawnego ORMa. Szybkość i wygoda rozwoju oprogramowania przy użyciu baz NoSQL jest zdecydowanie jednym z największych atutów tego rodzaju baz. Dodanie nowej właściwości/pola do obiektu to dosłownie kwestia dodania tego właśnie pola- nic więcej nie trzeba robić. Oczywiście można użyć argumentu że łatwo o wprowadzenie breaking changes, jednakże po tych 2 latach mojego obcowania z NoSQL mogę śmiało stwierdzić że jeśli utrzymuje się czysty kod i rozsądnie wprowadza przemyślane zmiany to bardzo łatwo zapobiec takim problemom.

Następnym argumentem jest prędkość i skalowalność- oczywiście tutaj można polemizować, ale ogólnie bazy NoSQL znane są właśnie z tego że jednym z ich głównych atutów jest prędkość oraz skalowalność. To oczywiście zazwyczaj przychodzi kosztem braku transakcyjności i integralności danych, chociaż i to nie jest takie oczywiste. Są bazy które od dawna wspierają transakcyjność (np. ACID przy zapisach i BASE przy odczytach), nawet na poziomie rozproszonym.

A skoro o integralności mowa- tu znów polecę kontrowersyjnie i stwierdzę że często to również nie ma znaczenia, i integralność referencyjna nie powinna być czymś domyślnie pożądanym. Często to właśnie aplikacja może poradzić sobie z takimi problemami. Np. możemy zapisać do bazy encję która posiada ID innej, nie istniejącej encji. Z braku integralności nie jesteśmy w stanie tego wykryć na etapie zapisu. Tylko czy jest to problemem? Otóż moim zdaniem nie. Takie rzeczy można obsłużyć w logice aplikacji bezpośrednio przed zapisem, lub później kiedy faktycznie ta nie istniejąca encja będzie nam potrzebna. To oczywiście zależy od natury konkretnej aplikacji i wymogów biznesowych, ale efekt koniec końców pozostanie ten sam- będziemy mieli błąd niezależnie od tego czy mamy integralność referencyjną czy też nie.

SQL pozwala również na budowanie i automatyczne optymalizowanie (do pewnego stopnia) skomplikowanych zapytań. Ale znów jest to raczej młotek gdzie wszystko inne wygląda jak gwóźdź- bardzo często lepsze efekty można osiągnąć stosując konkretną bazę NoSQL do konkretnego problemu, lub stosując poliglotyczne (nie wiem czy to dobre określenie) podejście gdzie baza SQL jest jedynie elementem, a nie głównym medium przechowywania i wyciągania danych.

Reasumując- od kiedy zacząłem przygodę z NoSQL to jeszcze nie zderzyłem się z przypadkiem gdzie potrzebowałbym bazy SQL. Dobrowolnie użyłem jej tylko raz do domowej aplikacji, i tylko dla tego że hosting na którym mam wystawioną stronę ma od razu w cenie bazę MSSQL. Zdaję sobię sprawę że są sytuacje kiedy faktycznie to baza SQL będzie potrzebna, ale jestem przekonany że są to raczej wyjątki niż norma a dzisiejsza popularność SQL bierze się z tego że jest to coś dobrze znanego, sprawdzonego, ustandaryzowanego i że przejście na NoSQL wiążę się z ze zmianą sposobu myślenia. Mimo wszystko moim zdaniem warto podjąć wyzwanie, bo bazy NoSQL niosą ze sobą wiele korzyści. Szczególnie takie korzyści które znacznie ułatwiają codzienną pracę.

Jak to wygląda u Was? Używacie/używaliście jakichkolwiek baz NoSQL? Rozważacie ich naukę albo wdrożenie u siebie w pracy?

Twój post potyka się na jednym, ale ważnym słowie.
NoSQL

Ono nie oznacza niczego technicznego, merytorycznego. To słowo IT-marketingu, taki nawias na bardzo różniące się pomysły i wykonania.
Bazą NoSQL jest np Berkeley DB obecnie przechrzczona pod Oracla. (key-value)

Bez określenia, jaką dziedzinę rozwiązujemy, z jakimi zagadnieniami się mierzymy, odpowiedź na "jaką bazę NoSQL wybrać" jest niemożliwe.
Chyba że "to na rekrutację", to wtedy Mongo DB.

Post, mówiąc o "worku" NoSQL ma bardzo niską wartość. Plus szczegóły, np o integralności referencyjnej SQL, gdzie się ślizgasz po wierzchu, nie podejmując głębszych rzeczy

Nie wiem dla czego uważasz że post się "potyka" o użycie słowa NoSQL skoro jest to określenie które już się od dawna przyjęło (słusznie lub nie) i odnosi się ogólnie do wszelkich baz bez ściśle określonej schema (nie znam polskiego odpowiednika). W treści posta odnoszę się właśnie do baz a nie konkretnej bazy NoSQL, gdyż to właśnie cechy które prawie wszystkie bazy NoSQL wspólnie posiadają sprawiają że wysuwam tezę taką a nie inną. To całe narzekanie na określenie NoSQL powtarzane jak mantra jest w zasadzie tak samo absurdalne jak wojenki typu "SQL umarło! A nie prawda, bo NoSQL umarło!". Ogólnie w branży wiadomo o co chodzi jeśli mowa o NoSQL, ale zawsze musi się pojawić jeździec na białym koniu obwieszający wszystkim dokoła że NoSQL nie oznacza żadnej konkretnej bazy ani technologii. Czyli to co wszyscy i tak wiedzą.

A ja jeszcze raz zaznaczam- w poście wyraźnie odnoszę się do szeroko rozumianych baz NoSQL, i ich cech wspólnych.

Plus szczegóły, np o integralności referencyjnej SQL, gdzie się ślizgasz po wierzchu, nie podejmując głębszych rzeczy

Zachęcam do przedstawienia Twojego punktu widzenia. Ja jasno napisałem że od kiedy zacząłem używać NoSQL- zarówno zawodowo jak i prywatnie- to nie spotkałem się jeszcze z potrzebą skorzystania z zalet SQL, takich jak właśnie integralność referencyjna. Między innymi po to założyłem ten wątek- uważasz inaczej, masz inne doświadczenie w tej dziedzinie? Podziel się tym. Pisaniem o niskiej wartości postu nic nie wnosisz do dyskusji, poza automatycznym stawieniem siebie w opozycji. W dodatku nie podpartej kontrargumentami.

Bez określenia, jaką dziedzinę rozwiązujemy, z jakimi zagadnieniami się mierzymy, odpowiedź na "jaką bazę NoSQL wybrać" jest niemożliwe.

Takie pytanie nigdzie tu nie pada. Wątek w ogóle nie jest o tym, może stąd Twoje niezrozumienie w czym rzecz.

Postgres na azurejest tańszy niż cosmos, więc wolę sql - poza tym, to schemat relacyjnej bazy mam generowany z kodu, jak są bazy nosql ze schematem, to którą wybrałbym zależałoby od domeny - jak można byłoby wydzielić agregaty które nie będą miały do siebie nawzajem referencji, to nosql, inaczej sql, nie widze miejsca na 'co lepsze' - ta kiełbasa lepsza, co komu lepiej smakuje.

Aventus napisał(a):

... mowa o NoSQL, ale zawsze musi się pojawić jeździec na białym koniu obwieszający wszystkim dokoła że NoSQL nie oznacza żadnej konkretnej bazy ani technologii. Czyli to co wszyscy i tak wiedzą.

Ale w czołówce był jeździec na czarnym koniu.

A ja jeszcze raz zaznaczam- w poście wyraźnie odnoszę się do szeroko rozumianych baz NoSQL, i ich cech wspólnych.

Plus szczegóły, np o integralności referencyjnej SQL, gdzie się ślizgasz po wierzchu, nie podejmując głębszych rzeczy

Zachęcam do przedstawienia Twojego punktu widzenia. Ja jasno napisałem że od kiedy zacząłem używać NoSQL- zarówno zawodowo jak i prywatnie- to nie spotkałem się jeszcze z potrzebą skorzystania z zalet SQL, takich jak właśnie integralność referencyjna. Między innymi po to założyłem ten wątek- uważasz inaczej, masz inne doświadczenie w tej dziedzinie? Podziel się tym. Pisaniem o niskiej wartości postu nic nie wnosisz do dyskusji, poza automatycznym stawieniem siebie w opozycji. W dodatku nie podpartej kontrargumentami.

Zrobienie tabel SQL bez mocnej referencji kluczy jest w pełni możliwe, czasem trafiam na to w projektach (profesjonalnych - o studenckich nie mówię). Jest to mniejszość, w uzasadnionych miejscach.

Piszesz też przerzuceniu zagadnień integralności na kod kliencki (warstwę wyżej).
Ale to działa (zwykle) źle, przez wielość kwerend, lokalną "transakcyjność" i jeszcze kilku powodów.

@Aventus:

integralność referencyjna nie powinna być czymś domyślnie pożądanym. Często to właśnie aplikacja może poradzić sobie z takimi problemami. Np. możemy zapisać do bazy encję która posiada ID innej, nie istniejącej encji. Z braku integralności nie jesteśmy w stanie tego wykryć na etapie zapisu. Tylko czy jest to problemem? Otóż moim zdaniem nie. Takie rzeczy można obsłużyć w logice aplikacji bezpośrednio przed zapisem, lub później kiedy faktycznie ta nie istniejąca encja będzie nam potrzebna. To oczywiście zależy od natury konkretnej aplikacji i wymogów biznesowych, ale efekt koniec końców pozostanie ten sam- będziemy mieli błąd niezależnie od tego czy mamy integralność referencyjną czy też nie.

Nie wiem czy dobrze rozumiem, ale mam pisać kod, który ma nadrabiać brak reliability bazy?

Zrobienie tabel SQL bez mocnej referencji kluczy jest w pełni możliwe, czasem trafiam na to w projektach (profesjonalnych - o studenckich nie mówię). Jest to mniejszość, w uzasadnionych miejscach.

Oczywiście że jest to możliwe. Nijak to się ma do tego co napisałem- a mianowicie że ta właśnie cecha SQL która może być ważnym atutem przy wyborze takiej a nie innej bazy, często jest tak naprawdę niepotrzebna. Znacznie częściej niż nam się wydaje.

Piszesz też przerzuceniu zagadnień integralności na kod kliencki (warstwę wyżej).
Ale to działa (zwykle) źle, przez wielość kwerend, lokalną "transakcyjność" i jeszcze kilku powodów.

Tylko jeśli próbujemy modelować tak jakbyśmy używali bazy relacyjnej, nie mając jej. Oczywiście że próba bawienia się w relacyjność przy użyciu jakiejkolwiek bazy NoSQL nie skończy się dobrze. Ale nie jest to wina narzędzia tylko tego kto tego narzędzia źle używa. Nawet wspomniane przez Ciebie poleganie na "transakcyjności" to często efekt złego modelowania domeny. Nie mówiąc już o tym że- jak już wspomniałem w pierwszym poście- są bazy NoSQL mające pełne wsparcie dla transakcji, w tym transakcji rozproszonych (obejmujące cały klaster).

Nie wiem czy dobrze rozumiem, ale mam pisać kod, który ma nadrabiać brak reliability bazy?

I tak, i nie. Tak, ponieważ jak wspomniałem wyżej przy nieodpowiednim modelowaniu nie unikniemy tego. Nie, ponieważ przy odpowiednim modelowaniu danych takie sprawdzanie "referencji" zazwyczaj nie będzie potrzebne, ponieważ w większości przypadków potrzebne dane zostaną załadowane jako jedna encja (dokument). Znów wspomnieć należy o porzuceniu rozumowania relacyjnego na rzecz innego podejścia do modelowania danych/domeny. A tam gdzie należy "doładować" dodatkowe encje i tak trzeba sprawdzić czy istnieją- bez znaczenia czy używasz bazy NoSQL czy SQL No bo pomyśl- jeśli masz encję A która ma referencje do encji B to przy integralności referencyjnej zakładasz że nie dasz rady zapisać encji A z referencją do nieistniejącej encji B. Ale czy przy ładowaniu tych encji w aplikacji będziesz ślepo zakładał żę encja B zawsze istnieje, skoro załadowałeś A? Innymi słowy- czy nigdy, w żadnym miejscu aplikacji nie sprawdzisz czy faktycznie B istnieje, i nie jest np. nullem?

Generalnie zastanawiałem się "Po co NoSQL(schemaless/dokumenty) jeżeli większość danych w biznesie jest bardzo relacyjna?"

I gdy zobaczyłem podejście hybrydowe jako performance booster (zapis do np. postgresa + mongo, a odczyt tylko z mongo), to znów nie potrafiłem odpowiedzieć "czemu by nie pójść w tylko nosql?"

nie wiem, te bazy jakieś skomplikowane są :D

@WeiXiao: no ja właśnie po tym dwuletnim obcowaniu z NoSQL nie napotkałem jeszcze przypadku gdzie chciałbym wrócić do SQL. Raz jeszcze podkreślam- z pewnością są sytuacje gdzie taka potrzeba jest, staram się jedynie powiedzieć że zazwyczaj stosujemy SQL tam gdzie tak naprawdę można korzystać z czegoś o wiele przyjemniejszego i wygodniejszego w użytkowaniu. Zapewne bierze się to z przywiązania do technologii które się już zna, i ja sam kiedyś byłem w takiej sytuacji- zastanawiałem się po co to całe NoSQL, jak rozwiązać problem X który w SQL jest rozwiązany w taki a nie inny sposób. Okazało się że często problemy które chcemy rozwiązać są problemami które sami tworzymy (wspomniana przeze mnie referencyjna integralność), i w wielu przypadkach tak naprawdę nie mają znaczenia. Podobnie miałem kiedy wchodziłem w świat eventual consistency. Wtedy wydawało mi się że strong consistency jest nieodzownym elementem jakiegokolwiek większego systemu, dziś śmiem twierdzić że wcale tak nie jest i paradoksalnie często to właśnie eventual consistency jest bardziej "naturalnym" odzwierciedleniem przepływu danych w domenie, a co za tym idzie w aplikacji odzwierciedlającej daną domenę.

I gdy zobaczyłem podejście hybrydowe jako performance booster (zapis do np. postgresa + mongo, a odczyt tylko z mongo), to znów nie potrafiłem odpowiedzieć "czemu by nie pójść w tylko nosql?"

Dokładnie, o polyglot persistence wspomniałem w pierwszym poście. Tylko że znów- odnosząc się do podlinkowanej prezentacji- traktowanie baz SQL jako synonimu transakcyjności jest błędne, ponieważ jak już wspominałem są bazy NoSQL które wspierają transakcje i są ACID compliant już od wielu lat także nie jest to nic nowego.

Po prostu tworzymy lub aktualizujemy klasę, tworzymy instancję tej klasy i zapisujemy do bazy. Nie trzeba zajmować się tworzeniem skryptów SQL czy migracji jeśli używamy jakiegoś pełnoprawnego ORMa. Szybkość i wygoda rozwoju oprogramowania przy użyciu baz NoSQL jest zdecydowanie jednym z największych atutów tego rodzaju baz. Dodanie nowej właściwości/pola do obiektu to dosłownie kwestia dodania tego właśnie pola- nic więcej nie trzeba robić.

Jeżeli pobieranie samych obiektów to wszystko co potrzebujemy, to i owszem. Tyle, że zaletą tych modeli relacyjnych jest właśnie możliwość wydobywania danych zgodnie z ich relacjami i wykonywanie złączeń.

Następnym argumentem jest prędkość i skalowalność- oczywiście tutaj można polemizować, ale ogólnie bazy NoSQL znane są właśnie z tego że jednym z ich głównych atutów jest prędkość oraz skalowalność.

A po co ci ta skalowalność? Odsyłam do klasycznego tekstu you are not google. Rzadko kiedy będziesz miał na tyle tych danych, że faktycznie potrzebne będzie ich dzielenie na wiele maszyn. Dla mnie zawsze uderzającym przykładem jest architektura stack overflow - wszystko siedzi na 2 bazach SQL Server (plus repliki na wypadek awarii). Całe SO siedzi na jednej bazie, reszta podstron na drugiej. Miliony pytań, odpowiedzi, komentarzy, plusów i minusów, a jakoś nie brakło miejsca i nie trzeba koniecznie rozpraszać na wiele serwerów.

Za dużo różnych firm i projektów wierzy w tego bożka skalowalności i ładuje się w te rozproszone bazy aby kiedyś w przyszłości być w stanie shardować te legendarne big data, po czym nie są w stanie przekroczyć 20000 użytkowników.

A skoro o integralności mowa- tu znów polecę kontrowersyjnie i stwierdzę że często to również nie ma znaczenia, i integralność referencyjna nie powinna być czymś domyślnie pożądanym. Często to właśnie aplikacja może poradzić sobie z takimi problemami. Np. możemy zapisać do bazy encję która posiada ID innej, nie istniejącej encji. Z braku integralności nie jesteśmy w stanie tego wykryć na etapie zapisu. Tylko czy jest to problemem? Otóż moim zdaniem nie. Takie rzeczy można obsłużyć w logice aplikacji bezpośrednio przed zapisem, lub później kiedy faktycznie ta nie istniejąca encja będzie nam potrzebna. To oczywiście zależy od natury konkretnej aplikacji i wymogów biznesowych, ale efekt koniec końców pozostanie ten sam- będziemy mieli błąd niezależnie od tego czy mamy integralność referencyjną czy też nie.

W programowaniu cały dowcip tkwi w tym żeby wybierać dobre narzędzie do odpowiedniego celu. Dlatego NoSQL to dobry magazyn danych na przykład na metryki i logi - tam faktycznie da się przeżyć, że jakiś zapis się zgubi. Tam też użycie tych technologii jest jak najbardziej w porządku. Natomiast dane płatności klientów wolałbym jednak mieć ściśle kontrolowane, bo tu już błędy są trudne do wybaczenia. I tutaj wolałbym jednak tę sztywną schemę i twarde reguły.

Jak to wygląda u Was? Używacie/używaliście jakichkolwiek baz NoSQL? Rozważacie ich naukę albo wdrożenie u siebie w pracy?

Widziałem na produkcji Mongo, weszło właśnie bo ktoś się zachłysnął tą całą nowością, a przecież my, nowocześni programiści, używamy tylko najnowocześniejszych hip and trendy technologii, a nie antyków jak modele relacyjne, co nie? Nikt tego nie lubił i ludzie pluli sobie w brodę tym pomysłem. W jednym projekcie zmigrowano na Postgresa, inny w innej firmie zdechł sam. Czy to wina NoSQL czy Mongo? Raczej Mongo, to trochę nieszczęsna technologia i chyba mało kto ją lubi (patrząc na różne dyskusje na redditach, szczególnie ci, którzy spróbowali jej użyć na produkcji xD). Inne bazy jak chociażby Redis używa się regularnie, gdzie pasują.

Ogółem, TLDR: narzędzia dobiera się w zależności od potrzeb i środków na podstawie analizy konkretnego problemu jaki się rozwiązuje. Czasem nawet baza nie jest potrzebna i wszystko można trzymać w gołych plikach. Z moich własnych doświadczeń, stosowałbym SQL do głównych, cennych danych biznesowych i NoSQL, tam, gdzie pasuje (logi, metryki, tymczasowe tokeny itd itp).

Spearhead napisał(a):

Jeżeli pobieranie samych obiektów to wszystko co potrzebujemy, to i owszem. Tyle, że zaletą tych modeli relacyjnych jest właśnie możliwość wydobywania danych zgodnie z ich relacjami i wykonywanie złączeń.

Ale to również można robić w wielu bazach NoSQL, szczególnie wspierających dokumenty i grafy. Poza tym jeśli konieczne jest dokonywanie wielu złączeń i ładowanie skomplikowanych relacji to znów się powtórzę i stwierdzę że używamy bazy SQL do rozwiązania problemu który sami stworzyliśmy. A jeśli mamy dużo zagnieżdżonych powiązań między encjami to o ironio, tak się składa że to właśnie bazy grafowe nadają się najlepiej do takich problemów!

A po co ci ta skalowalność? Odsyłam do klasycznego tekstu you are not google. Rzadko kiedy będziesz miał na tyle tych danych, że faktycznie potrzebne będzie ich dzielenie na wiele maszyn. Dla mnie zawsze uderzającym przykładem jest architektura stack overflow - wszystko siedzi na 2 bazach SQL Server (plus repliki na wypadek awarii). Całe SO siedzi na jednej bazie, reszta podstron na drugiej. Miliony pytań, odpowiedzi, komentarzy, plusów i minusów, a jakoś nie brakło miejsca i nie trzeba koniecznie rozpraszać na wiele serwerów.

Argument "you are not google" można stosować w zasadzie wszędzie, nie zmieni to faktu że jest masa systemów które właśnie wymagają dobrej skalowalności. Owszem, może i sporo się dzieję na takim SO, ale to akurat słaby kontr-przykład bo nijak można przepustowość danych i częstotliwość zapisów/zapytań porównać do wielu systemów, np. finansowych.

Za dużo różnych firm i projektów wierzy w tego bożka skalowalności i ładuje się w te rozproszone bazy aby kiedyś w przyszłości być w stanie shardować te legendarne big data, po czym nie są w stanie przekroczyć 20000 użytkowników.

Nie twierdzę że tak nie jest, ale w takim razie problem tkwi na etapie definiowania wymagań i tworzenia systemu pod te wymagania.

W programowaniu cały dowcip tkwi w tym żeby wybierać dobre narzędzie do odpowiedniego celu.

W pełni się z tym zgadzam, tym bardziej ironiczne mi się wydaje z jaką zaciekłością wiele osób reaguje na temat NoSQL, i jako domyślne rozwiązanie stosuje bazy SQL. To jeden z moich argumentów tego wątku- jeśli już, to moim zdaniem z dwojga złego lepszym "młotkiem na gwoździe" jest NoSQL chociażby ze względu na łatwość z jaką się z takich baz korzysta i dokonuje zmian modelu domenowego. Później można pomyśleć o zastosowaniu baz relacyjnych jeśli faktycznie zaistnieje taka potrzeba.

Dlatego NoSQL to dobry magazyn danych na przykład na metryki i logi - tam faktycznie da się przeżyć, że jakiś zapis się zgubi. Tam też użycie tych technologii jest jak najbardziej w porządku. Natomiast dane płatności klientów wolałbym jednak mieć ściśle kontrolowane, bo tu już błędy są trudne do wybaczenia. I tutaj wolałbym jednak tę sztywną schemę i twarde reguły.

Całkowicie się z tym nie zgadzam. Po pierwsze co rozumiesz przez zgubienie zapisu? Nic takiego nie ma szans się stać w żadnej szanującej się bazie danych, czy to NoSQL czy SQL. A schema nijak ma się do ścisłej kontroli zapisów płatności. Jeśli o transakcjach płatniczych mowa, to do ich niezawodności i dokładności powstały świetne rozwiązania "logiczne", a nie technologiczne. Chociażby event sourcing, przy którym baza danych to jedynie szczegół implementacyjny.

Widziałem na produkcji Mongo, weszło właśnie bo ktoś się zachłysnął tą całą nowością, a przecież my, nowocześni programiści, używamy tylko najnowocześniejszych hip and trendy technologii, a nie antyków jak modele relacyjne, co nie? Nikt tego nie lubił i ludzie pluli sobie w brodę tym pomysłem. W jednym projekcie zmigrowano na Postgresa, inny w innej firmie zdechł sam. Czy to wina NoSQL czy Mongo? Raczej Mongo, to trochę nieszczęsna technologia i chyba mało kto ją lubi (patrząc na różne dyskusje na redditach, szczególnie ci, którzy spróbowali jej użyć na produkcji xD). Inne bazy jak chociażby Redis używa się regularnie, gdzie pasują.

Ja na początku kariery w branży długo wstrzymywałem się przed nauką ORMów, bo starszy stażem programista powiedział że 5 lat wcześniej używał i to była klapa... W zasadzie taka logika stwierdzenia że "coś się widziało, coś słyszało, tam nie wypaliło i o". Nie odnoszę się konkretnie do MongoDB (notabene ostatnio pojawiły się jakieś zarzuty odnośnie tej bazy, a konkretnie poważnych problemów z transakcjami) ale ogólnie do takiego podejścia jakie właśnie przedstawiłeś. Większość błędów to zazwyczaj wina nieumiejętnego korzystania z narzędzia, a nie narzędzia samego w sobie. Ten sam błąd myślowy nie raz widziałem odnośnie event sourcingu czy DDD, nawet niejednokrotnie tutaj na forum. Czyli "zrobimy po swojemu a nie jak należy, a później obwinimy technologię/wzorzec". Co do samego hejtu to czym coś jest popularniejsze, tym więcej niezadowolonych głosów się znajdzie.

Ogółem, TLDR: narzędzia dobiera się w zależności od potrzeb i środków na podstawie analizy konkretnego problemu jaki się rozwiązuje. Czasem nawet baza nie jest potrzebna i wszystko można trzymać w gołych plikach. Z moich własnych doświadczeń, stosowałbym SQL do głównych, cennych danych biznesowych i NoSQL, tam, gdzie pasuje (logi, metryki, tymczasowe tokeny itd itp).

No i znów podkreślę paradoks powtarzający się w tej dyskusji- stosować narzędzie zależnie od potrzeb, ale wiecie- tak domyślnie to SQL. No a ja właśnie przedstawiłem inny punkt widzenia, chociaż widząc po odpowiedziach i lajkach na niektórych widzę że jeszcze długa droga zanim więcej programistów uświadomi sobie że szkoda marnować czas kiedy są o wiele przyjemniejsze narzędzia. Mam tylko nadzieję że ten wątek zachęci chociaż odrobinę czytelników do większego zagłębienia się w temat i ułatwienia sobie życia.

http://blog.cleancoder.com/uncle-bob/2012/05/15/NODB.html

@jarekr000000: dobry artykuł, już go kiedyś widziałem. Rzecz w tym że... on w zasadzie potwierdza moją tezę. Załóżmy że nie chcemy zakładać z jaką bazą skończymy, tym bardziej najlepiej zacząć z bazą NoSQ, np. wspierającą dokumenty! Zamiast babrać się w modelowanie schema, tworzenie skryptów (czy to ręcznie czy za pomocą jakieś ORMa), migracje itp. można zapisać encję tak:

store.Save(myEntity)

Zakładając że store to jakiś provider pochodzący z konkretnej bazy którą używamy. I już, gotowe. Czyli pozwala nam to na skupienie się na tym co ja zawsze promuje- modelu domenowym.

A mają te NoSQL triggery?

Marcin.Miga napisał(a):

A mają te NoSQL triggery?

Niestety, niektóre mają lub miały.
Ale na szczęście są raczej rzadko (w porównaniu do SQL) używane.

Jak to wygląda u Was? Używacie/używaliście jakichkolwiek baz NoSQL? Rozważacie ich naukę albo wdrożenie u siebie w pracy?

nie znam nosql, ale znam kilka przypadków gdzie dany task obkodowany w procedurze był dużo wydajniejszy niż po stronie aplikacji

@biela_: Znów powtórzę- to często przejaw złego modelowania domeny, a więc używając półśrodków takich jak triggery naprawiamy objaw, ale nie przyczynę problemu.

Fajny wywód, ale wydaje mi się, że mam kilka nieścisłości.

Aventus napisał(a):

Dzięki NoSQL możemy skupiać się na modelowaniu domeny naszej aplikacji i nie przejmować (w granicach rozsądku) "kształtem" obiektów zapisywanych do bazy. Po prostu tworzymy lub aktualizujemy klasę, tworzymy instancję tej klasy i zapisujemy do bazy. Nie trzeba zajmować się tworzeniem skryptów SQL czy migracji jeśli używamy jakiegoś pełnoprawnego ORMa. Szybkość i wygoda rozwoju oprogramowania przy użyciu baz NoSQL jest zdecydowanie jednym z największych atutów tego rodzaju baz. Dodanie nowej właściwości/pola do obiektu to dosłownie kwestia dodania tego właśnie pola- nic więcej nie trzeba robić.

A przy małym fajnie zaprojektowanym module można mieć to samo przy bazie SQL i to też bez żadnych sqlek nawet i klucze i constrainty nam potworzy.

Następnym argumentem jest prędkość i skalowalność- oczywiście tutaj można polemizować, ale ogólnie bazy NoSQL znane są właśnie z tego że jednym z ich głównych atutów jest prędkość oraz skalowalność.

A prędkość i skalowalność? To ciekawe, bo jakoś ostatni pierwszy przykład z brzegu - administrator tego forum wykonał niedawno test porównawczy kilku baz. Odpalił je bez większego wchodzenia w szczegóły i konfiguracje - tzw. out of the box na przeciętnym komputerze. I co się okazało? Otóż okazało się, że standardowa baza SQL napisana w języku ANSI C wypadła lepiej niż bazy NoSQL a w sumie to wypadła najlepiej. W nowym projekcie potrzebuje... . Więc jaka to skalowalność kiedy baza nie skaluje się na komputerze developerskim? A to jest bardzo istotne, bo przy developmencie programista czasem chce sobie coś zrobić na bazie a okazuje się, że np. ona zamula albo nawet nie może jej odpalić, bo nie starcza zasobów (patrz niektóre bazy ze stosu hadoop). To jest ważne też, bo programista to tak jakby Bóg maszyny - jego czas jest bardzo drogi i on swoimi palcami tworzy kolejne programy i oprogramowanie na maszyny. To jest żywy człowiek a nie kod czy maszyna. Dlatego niedopuszczalne jest aby baza danych mu w tym przeszkadzała i stawiała się jakoby wyżej niż komputer personalny i człowiek odmawiając uruchomienia się np. podczas jazdy w pociągu aby programista nie mógł jej uruchomić na swoim laptopie. Jedna z myśli, która przyświecała twórcom potężnych języków i systemów jak np. UNIX czy Linux, była skromna - taka, aby te systemy zadziałały na zwykłym słabym sprzęcie zwykłych ludzi. Miały to być systemy wszystkich ludzi i wszystkich Polaków - Podejrzewano, że prosta, mała, ale dobrze przemyślana architektura, zadziała nieźle również i na większych maszynach - superkomputerach czy klastrach. I to się wydarzyło. Obecnie Linux jest podwaliną wszystkich systemów, obsługując wielkie systemy giełdowe, małe komputerki jak raspberry pi, czy telefony komórkowe Android. Mam wrażenie, że twórcom niektórych wielkich nowoczesnych baz np. w języku Java przyświeca inne podejście i za kilka lat na te bazy będzie hejt

A skoro o integralności mowa- tu znów polecę kontrowersyjnie i stwierdzę że często to również nie ma znaczenia, i integralność referencyjna nie powinna być czymś domyślnie pożądanym. Często to właśnie aplikacja może poradzić sobie z takimi problemami. Np. możemy zapisać do bazy encję która posiada ID innej, nie istniejącej encji.
Z braku integralności nie jesteśmy w stanie tego wykryć na etapie zapisu. Tylko czy jest to problemem? Otóż moim zdaniem nie. Takie rzeczy można obsłużyć w logice aplikacji bezpośrednio przed zapisem, lub później kiedy faktycznie ta nie istniejąca encja będzie nam potrzebna.

Przeczysz sam sobie, bo piszesz Z braku integralności nie jesteśmy w stanie tego wykryć na etapie zapisu. co jest prawdą a potem piszesz Takie rzeczy można obsłużyć w logice aplikacji bezpośrednio przed zapisem . To brzmi jak proszenie się o błędy. Przecież jeżeli mam założyć na wstępie brak integralności i problemy przez to a mogę założyć restrykcyjnie integralność danych i brak problemów przez to to jasne, że wybiorę to drugie. Nie wyobrażam sobie pisać aplikacji, która ma radzić sobie z niespójnymi danymi.

karolinaa napisał(a):

A przy małym fajnie zaprojektowanym module można mieć to samo przy bazie SQL i to też bez żadnych sqlek nawet i klucze i constrainty nam potworzy.

Co masz na myśli pisząc o "małym fajnie zaprojektowanym module"? Nie do końca rozumiem. I tak nie unikniesz zarządzania schemą, czy to pośrednio (skrypty SQL) czy bezpośrednio (ORM).

A prędkość i skalowalność? To ciekawe, bo jakoś ostatni pierwszy przykład z brzegu - administrator tego forum wykonał niedawno test porównawczy kilku baz(...)

Jak już wcześniej wspominałem- owszem, często SQL zupełnie wystarczy, ale często (nawet jeśli nie jesteśmy Google) w rozbudowanych systemach enterprise, obsługujących miliony transakcji na porządku dziennym taka skalowalność jest potrzebna. Co i tak nie zmienia faktu że nawet wyrzucając skalowalność z dyskusji to największym atutem NoSQL który tutaj postuluje jest wygoda programisty pisania systemów opartych o NoSQL.

Przeczysz sam sobie, bo piszesz Z braku integralności nie jesteśmy w stanie tego wykryć na etapie zapisu. co jest prawdą a potem piszesz Takie rzeczy można obsłużyć w logice aplikacji bezpośrednio przed zapisem .

Sprzeczności tu nie ma, być może nie wyraziłem się dobitnie jasno. Pisząc na etapie zapisu odnosiłem się do zapisu po stronie bazy, tam gdzie baza SQL ma kontrolę nad integralnością. A więc korzystając z bazy NoSQL nie mamy takiej możliwości, stąd wspomniana możliwość sprawdzania takich rzeczy w logice aplikacji- ale tam gdzie faktycznie jest taka potrzeba, ponieważ- powtórzę się po raz kolejny i kolejny- przy prawidłowym, nie-relacyjnym modelowaniu danych sprawdzanie referencji to przypadki wyjątkowe, a nie reguła.

To brzmi jak proszenie się o błędy.

Tylko dla kogoś kto mentalnie siedzi wyłącznie w świecie relacyjnym i nie miał namacalnego doświadczenia z systemami korzystającymi z NoSQL, modelując dane jako np. dokumenty.

Przecież jeżeli mam założyć na wstępie brak integralności i problemy przez to a mogę założyć restrykcyjnie integralność danych i brak problemów przez to to jasne, że wybiorę to drugie.

I znów się powtórzę (mam już wrażenie że piszę do większości osób jak do ściany)- to co piszesz ma sens tylko jeśli pozostajemy mentalnie w modelu relacyjnym. Ale weźmy krok wstecz- co w większości przypadków daje Ci ta integralność, zakładając że piszesz coś więcej niż zwykłego CRUDa? To że baza danych wywali Ci błędem? No brawo, i co z tym zrobisz? Wyślesz ten błąd z powrotem do użytkownika czy zapakujesz w jakąś nic nikomu nie mówiącą, generyczną wiadomość? Jeśli będziesz miała odpowiednio zamodelowną domenę to w większości przypadków takie ryzyko zwyczajnie nie będzie istnieć, a tam gdzie faktycznie będzie trzeba sprawdzić czy referencja istnieje obsłużysz to zgrabnie w logice aplikacji dzięki czemu powiesz użytkownikowi dokładnie co należy zrobić żeby rozwiązać problem, np. "Aby dodać X, najpierw musisz utworzyć Y".

Nie wyobrażam sobie pisać aplikacji, która ma radzić sobie z niespójnymi danymi.

Widocznie nigdy nie miałaś styczności chociażby z systemami które są eventually consistent. I nie ma w tym nic złego, ale już zaciekłe bronienie jednego podejścia tylko dla tego że nie było się wystawionym na inne jest błędem. To tak jakby programista OOP mówił że nie wyobraża sobie pisać aplikacji funkcyjnie, i vice versa. Można sobie czegoś nie wyobrażać, tylko wtedy udowadniamy jak ograniczone horyzonty (programistyczne) mamy i jak oporni jesteśmy do poznania innych sposobów rozwiązywania problemów. Więc znów wypomnę ten paradoks- ci którzy najbardziej krzyczą żeby dobierać odpowiednie narzędzie do zadania, wykazują się największą opornością na poznanie właśnie innych narzędzi i traktują SQL jak ten "młotek na gwoździe". Dziwię się że naprawdę tak mało osób w tym wątku dostrzega ten paradoks.

Mówimy Partia, a myślimy Lenin (pamiętam dzieciem będąc, koledzy z łapanki deklamowali na akademii "ku czci").

Mówimy NoSQL a myślimy Mongo (filozofia dokumentowa). To może mówić wprost?

AnyKtokolwiek napisał(a):

Mówimy Partia, a myślimy Lenin (pamiętam dzieciem będąc, koledzy z łapanki deklamowali na akademii "ku czci").

Mówimy NoSQL a myślimy Mongo (filozofia dokumentowa). To może mówić wprost?

Niestety. A przecież od 2015 roku najlepszą bazą dokumentową jest PostgreSQL wspierający zapytania dla dokumentów JSONB. Idealnie łączy on zalety bazy relacyjnej i dokumentowej

@AnyKtokolwiek: sugerujesz że jeśli mowa o bazach dokumentowych to mowa tylko o MongoDB? W pierwszym poście który napisałeś w tym wątku zarzuciłeś niską wartość merytoryczną, nie dając żadnych konkretnych argumentów a później rzucając jakieś ogólniki. Teraz próbujesz stworzyć wrażenie jakby nie było innych baz dokumentowych oprócz MongoDB (z którym notabene mam minimalne doświadczenie i którego od tych dwóch lat nie używałem) i wprowadzając tym samym innych w błąd. Nie wiem czy Ty tak na poważnie czy to już trolling. Albo zwyczajne zaślepienie?

Proszę bardzo, w miejsce gdzie pisałem NoSQL wstaw "bazy dokumentowe". Bazy, nie MongoDB. Wszystko co napisałem będzie nadal ważne.

Co do głównego wątku to się nie wypowiem, bo nie znam NoSQL, ale trochę sam już się zapętlasz z argumentami: dorobienie obsługi błędów do SQL to be:

Aventus napisał(a):

... To że baza danych wywali Ci błędem? No brawo, i co z tym zrobisz? Wyślesz ten błąd z powrotem do użytkownika czy zapakujesz w jakąś nic nikomu nie mówiącą, generyczną wiadomość?

ale w przypadku NoSQL już ok:

Jeśli będziesz miała odpowiednio zamodelowną domenę to w większości przypadków takie ryzyko zwyczajnie nie będzie istnieć, a tam gdzie faktycznie będzie trzeba sprawdzić czy referencja istnieje obsłużysz to zgrabnie w logice aplikacji dzięki czemu powiesz użytkownikowi dokładnie co należy zrobić żeby rozwiązać problem, np. "Aby dodać X, najpierw musisz utworzyć Y". ...

@Paweł Dmitruk: ty chyba nie zrozumiałeś w ogóle tego co ja tam napisałem. Tam nie ma zaprzeczenia, drugi cytat jest kontynuacją pierwszego i opisuje obsłużenie błędu aplikacji w sposób najbardziej pomagający użytkownikowi, zamiast rzucenie jakimś generycznym błędem- co się stanie jeśli baza najzwyczajniej w świecie wywali Ci pogwałcenie integralności. Bo jeśli jawnie nie sprawdzisz w aplikacji czy encja X istnieje czy też nie, to skąd to będziesz wiedział kiedy baza danych rzuci wyjątek? Wtedy musisz zwrócić do użytkownika generyczny błąd (coś poszło nie tak) zamiast powiedzieć użytkownikowi jak to naprawić.

Ale znów powtarzam bo zaraz się znowu ktoś zleci kto pominie najważniejszą kwestię o której już mówiłem- przy odpowiednim modelowaniu domeny takie sprawdzanie encji to wyjątki.

Nie ma tu żadnego zapętlania, co najwyżej problem z czytaniem ze zrozumieniem.

... takie sprawdzanie encji to wyjątki

Które i tak powinno się obsłużyć, tak samo jak w tym przypadku:

... baza najzwyczajniej w świecie wywali Ci pogwałcenie integralności ...

Co w przypadku przemyślanej struktury i poprawnych danych też będzie bardzo rzadkie.

Zacząłem czytać ten wątek bo wydał się ciekawy, ale kurcze - może faktycznie nie rozumiem - z każdym kolejnym Twoim postem odnoszę wrażenie, że na siłę próbujesz wmówić, że sql jest be i lepiej wybrać NoSQL. A non stop lecisz tymi samymi ogólnikami.

Mimo wszystko rozbudziłeś moja ciekawość w tym temacie, za co dziękuję.

Wyluzujcie :-) każdy niech używa do lubi. Mnie bawi bardzo poniższy tekst

– To jak ty się właściwie nazywasz, bo zapomniałem. Kongo? Srongo?
– Mongo.
– A więc uważnie mnie posłuchaj, Mongoł. Byłeś w relacjach?
– Nie.
– No właśnie, a ja znam kogoś, kto był i opowiedział mi to i owo. Wiesz, skąd się wzięli developerzy noSQL?
– Z linkedin?
– No właśnie, wpisali sobie na linkedin w umiejętnościach noSQL i HRy ich wypatrzyły. A czy ty myślisz, że to taka prosta sprawa wejść do netu, zaprosić na interview silnego, zwinnego Developera i kazać mu robić w noSQL?
– Chyba nie.
– No jasne, że nie. Udało im się to, ponieważ brali tylko takich, co nie potrafili spierdolić przed botami, napisać potrójnie zagnieżdżonego selecta albo byli największymi głąbami w plemieniu i team lead outsourcował ich za paczkę fajek, bo i tak nie miał z nich żadnego pożytku. I ci wszyscy nieudacznicy zaczęli robić w noSQL. Pożenili się, porobili dzieci, świat poszedł do przodu. Pojawił się git zamiast svna, porządne IDE, Oracle, Postgres, mySQL, MS SQL, ale co z tego, jeżeli ich ręce pompuję ten sam kod. Są potomkami człowieka, który dał się złapać przez HR w necie. Dlatego nie uważam, że relacyjnym bazom brakuje luzu? Kapujesz?

Paweł Dmitruk napisał(a):

Które i tak powinno się obsłużyć, tak samo jak w tym przypadku:

Tak, tylko w tym przypadku obsłużasz to tak że mówisz użytkownikowi dokładnie co poszło nie tak, zanim w ogóle cokolwiek wywaliło Ci jakiś błąd. I nie mówisz że coś się wykrzaczyło, tylko dajesz użytkownikowi znać "Hej, nie zrobiłeś tego...".

... baza najzwyczajniej w świecie wywali Ci pogwałcenie integralności ...

Co w przypadku przemyślanej struktury i poprawnych danych też będzie bardzo rzadkie.

No... tak. Czyli dokładnie to co pisałem już wcześniej, a więc w większości przypadków w ogóle nie potrzebujemy tego dodatkowego mechanizmu "bezpieczeństwa".

Zacząłem czytać ten wątek bo wydał się ciekawy, ale kurcze - może faktycznie nie rozumiem - z każdym kolejnym Twoim postem odnoszę wrażenie, że na siłę próbujesz wmówić, że sql jest be i lepiej wybrać NoSQL.

Znów- czytanie ze zrozumieniem się kłania. Ja nigdzie nie napisałem że SQL jest "be". Podkreślałem natomiast że moim zdaniem przy dzisiejszych technologiach nie powinien być **domyślnym ** wyborem, przede wszystkim ze względu na wygodę użytkowania baz NoSQL (zakładając oczywiście że nie próbujemy modelować w nich relacyjnie).

Mimo wszystko rozbudziłeś moja ciekawość w tym temacie, za co dziękuję.

To dobrze, proponuję zagłębić się w temat. Oczywiście między innymi ucząc się modelowania danych nie-relacyjnie. Jeśli mogę coś polecić w temacie, to tutaj oraz tutaj jest to dosyć fajnie przedstawione.

A non stop lecisz tymi samymi ogólnikami.

Jakby różne osoby na różne sposoby próbowały Ci powiedzieć że 2 + 2 nie równa się 4 tylko dla tego że operują w systemie binarnym i dla nich 2 oznacza 11, to też non stop byś leciał tym samym "ogólnikiem" że to jednak jest 4. Nie byłoby Twoją winą że do niektórych po prostu nie dociera, i nadal próbują postrzegać świat poprzez pryzmat że 2 i 2 daje nam 6.

@Aventus:
Jestem ciekaw - jakbyś taką bazę rzerobił na NoSQL (np. te słynne Mongo) - żeby można było łatwo i efektywnie wyciągać dane do raportów i żeby ogólnie miało sens.
Ogólnie jednak większość danych zapisujemy w modelu relacyjnym gdzie mamy powiązania.

Aventus napisał(a):

Paweł Dmitruk napisał(a):

Które i tak powinno się obsłużyć, tak samo jak w tym przypadku:

Tak, tylko w tym przypadku obsłużasz to tak że mówisz użytkownikowi dokładnie co poszło nie tak, zanim w ogóle cokolwiek wywaliło Ci jakiś błąd. I nie mówisz że coś się wykrzaczyło, tylko dajesz użytkownikowi znać "Hej, nie zrobiłeś tego...".

... baza najzwyczajniej w świecie wywali Ci pogwałcenie integralności ...

Co w przypadku przemyślanej struktury i poprawnych danych też będzie bardzo rzadkie.

No... tak. Czyli dokładnie to co pisałem już wcześniej, a więc w większości przypadków w ogóle nie potrzebujemy tego dodatkowego mechanizmu "bezpieczeństwa".

No właśnie sam piszesz, że dodajesz mechanizm bezpieczeństwa, tyle że w aplikacji. A przecież w sql można zrobić dodawanie za pomocą procedury, w której też mogę dokładnie zaprogramować zwrotną informację z opisaną przyczyną błędu. Ale też przecież można olać procedury sql i sprawdzać wszystko w kodzie aplikacji.

No ale fakt, że jeżeli nie dodasz tego mechanizmu bezpieczeństwa, to przy dodawaniu sql może walić błędami z czapy, co w sumie i tak jest wg mnie lepszym rozwiązaniem niż zapisywanie danych, które są mi zupełnie nie potrzebne.

A przecież w sql można zrobić dodawanie za pomocą procedury, w której też mogę dokładnie zaprogramować zwrotną informację z opisaną przyczyną błędu.

Nie chce tutaj wdawać się w polemikę bo to odrębny temat, ale rozpraszanie logiki biznesowej między aplikacje i procedury w bazie danych to dopiero przepis na potworka. To co właśnie zaproponowałeś to już w ogóle jakiś masakryczny workaround do tego co już opisałem wcześniej, czyli żeby obsłużyć takie rzeczy w kodzie. Poza tym z technicznego punktu widzenia owszem, można to obsłużyć po stronie bazy danych. Tylko co z tego że można? Czy faktycznie większość systemów tak robi? Oczywiście że nie, większość systemów po prostu zdaje się na domyślne błędy pogwałcenia integralności. Więc wracamy do punktu wyjścia tego co pisałem wcześniej.

No ale fakt, że jeżeli nie dodasz tego mechanizmu bezpieczeństwa, to przy dodawaniu sql może walić błędami z czapy, co w sumie i tak jest wg mnie lepszym rozwiązaniem niż zapisywanie danych, które są mi zupełnie nie potrzebne.

Nie rozumiem co masz na myśli pisząc o zapisywaniu rzeczy które są niepotrzebne. Ja nigdzie czegoś takiego nie sugerowałem.

@scibi92: Widzisz, ciekawe w jaki sposób pytasz o rozwiązanie problemu przy użyciu NoSQL. Nie wiem jak to zrobić w MongoDB ponieważ jak już wspomniałem nie mam z tą bazą zbyt wiele wspólnego. Ale przyjmijmy ze pytasz ogólnie o bazę dokumentową. Czemu twierdzę że to o co pytasz jest ciekawe? Bo podchodzisz do tematu od "tyłka" strony, i próbujesz rozwiązać problem modelowania domeny patrząc na to relacyjnie, zamiast tak jak należy- skupiając się na modelu domenowym, zasadach biznesowych i przepływie informacji w domenie. Tak się powinno w pierwszej kolejności podchodzić do tematu modelowania domeny, i nie ważne czy używamy SQL, NoSQL czy zapisujemy sobie dane w dokumencie teksotwym (taki żart). Zamiast skupiać się na danych, należy skupić się na zachowaniu systemu a bazę traktować jako sprawę drugorzędna. I znów wracamy do tego co mówiłem- stosując takie podejście NoSQL dużo ułatwia bo później mając gotowe obiekty domenowe po prostu zapisujemy je w całości do bazy. Nie musimy bawić się w normalizację, tworzenie relacji między obiektami które w rzeczywistości tworzą spójną całość itp. Co do pytania o wyciąganie raportów itp. to są bazy dokumentowe które świetnie sobie z tym radzą, a tak gdzie mimo wszystko potrzebne jest inne podejście (i np. zastosowanie SQL) to polemizowałbym że tym bardziej nie należy wszystkiego trzymać razem tylko zastosować CQRS. Bo skoro mamy tak zaawansowane wymagania do obsługi zapytań to na litość- nie katujmy nimi bazy która przechowuje obiekty domenowe. Zastosujmy do tego CQRS i obsłużmy zapytania po stronie odczytu (read side).