Pojawiło się sporo odpowiedzi więc na wstępnie zaznaczę że przepraszam ale z braku czasu nie dam rady do wszystkiego się ustosunkować. Miejscami będę musiał po prostu odpowiedzieć ogólnie tam gdzie wypadało by rozbić fragment wypowiedzi na więcej segmentów i do każdego odpowiedzieć oddzielnie.
@Aventus wielokrotnie podkreślasz wygodę NoSQL w porównaniu z SQL dlatego mam pytanie - w czym NoSQL jest lepszy od SQL z perspektywy programisty w 2020 roku?
- DB to szczegół implementacyjny, jakieś tam I/O device schowane gdzieś pod spodem, dopóki nie zaczynasz jawnie korzystać z ficzerów danego DBMS możesz relatywnie łatwo wymienić go na inny - przynajmniej w teorii
- najczęściej polegasz na istniejących już driverach i bibliotekach (szczególnie bez driverów byłoby ciężko), nawet jeśli budujesz sam zapytania - gdzieś po drodze wchodzi jakiś mapper / serializacja, nie piszesz raczej własnego boilerplate do mapowania rowów / JSONów / czegokolwiek na obiekty
- samych zapytań w 80% przypadków też raczej nie musisz składać bezpośrednio - nawet jeśli nie chcesz używać ORMa, są jeszcze DSLe i/lub LINQ które to ułatwiają
Przede wszystkim pisałem o wygodzie. Co do szczegółów implementacyjnych to sami siebie oszukujemy, bo jednak wybór bazy danych- tak, wliczając w to bazy NoSQL- ma swój narzut na to jak piszemy aplikację, jak modelujemy domenę itp. No chyba że lecimy w pełne wyabstrahowanie metody pezystencji danych, ale... tutaj nawet nie zaczynam tematu, bo i w tej dziedzinie toczone są wojenki. Co meritum tego paragrafu- już wymieniałem tę wygodę, przede wszystkim chodzi o brak konieczności zarządzania schemą, przez co w dużej mierze takie operacje jak zapisywanie i ładowanie danych mamy out of the box.
Jak już jesteśmy przy zapytaniach, nie widzę jakiejś szczególnej przewagi (...)
Ja również. Powiedziałbym nawet że pierwsza wersja jest brzydka. Tylko że jak już pisałem wcześniej, z MongoDB mam niewiele wspólnego więc nie do końca rozumiem czemu momentami jestem traktowany jakbym był adowaketem tej konkretnej technologii. Wiem, MongoDB to chyba najpopularniejsza dokumentowa baza, ale takich baz jest bardzo dużo, i co warte podkreślenia- są nowsze, robiące różne rzeczy lepiej i ze znacznie bogatszymi bibilotekami/driverami, np. wspierającymi LINQ.
Być może powodem, dla którego mógłbym chcieć wykorzystać np. bazę dokumentową zamiast relacyjnej jest problem N + 1, wokół którego parę postów już krążyło mówiąc o konieczności (lub nie) joinowania danych. Jak jest w SQL wszyscy wiemy, większa swoboda modelowania danych w np. bazach dokumentowych niż w SQL nam to ładnie rowiąże - ale z drugiej strony jak w bazie dokumentowej zaczniesz wprowadzać referencje, to masz dwie opcje
- baza wspiera rozwiązywanie tych referencji w ramach pojedynczego zapytania i pokrywa Twój przypadek
- baza nie wspiera tego w ogóle lub wspiera, ale nie pokrywa Twojego przypadku
To, w który przypadek wpadniesz zależy już od konkretnego DBMS i tego, jakie ma przydatne ficzury - ale znowu, tutaj uzależniasz się od konkretnego ficzura konkretnej DB. Wymienisz Mongo które ma $lookup i $graphLookup na jakieś inne FooDB, które nie ma odpowiednika lub jest znacznie uboższy, i wpadasz w wariant drugi - i te same problemy co w SQL.
No tak, ale to argument nie przemawiający ani za SQL ani NoSQL, bo dotyczy ich tak samo.
Obstawiam, że w 80% przypadków największym skutkiem wyboru SQL / NoSQL jako "domyślnego" podejścia byłby triumf fanboyów danego rozwiązania, a w pozostałych i tak wybiera się to, co wydaje się bardziej pasować do problemu.
Z tym się całkowicie nie zgadzam, wydaje mi się że my programiści lubimy się tak oszukiwać. W większości przypadków używamy tego do czego jesteśmy przyzwyczajeni, zresztą naturalnie poszukujemy uniwersalnych rozwiązań (przysłowiowy młotek). Ja np. nie oszukuję się że stosuję OOP a nie programowanie funkcyjne bo stosuje rozwiązanie które najbrdziej pasuje do danego problem, tylko po prostu nie znam FP na tyle żeby móc dokonać obiektywnego wyboru. Fanboystwa też w tym nie ma. Byłoby gdybym szedł w zaparte i twierdził że nie mam potrzeby stosować FP i tyle, bo OOP pasuje lepiej. Nie znam FP, więc nie mogę tak stwierdzić. Odnoszę natomiast wrażenie że niektórzy (nie wszyscy oczywiście) w tym wątku to właśnie ten drugi przypadek- tacy którzy twierdziliby że OOP bo jest lepsze, mimo że tego drugiego nie znają. Grunt to mieć trochę samokrytyki i zdawać sobie sprawę ze swojej niewiedzy na jakiś temat.
Domyślny wybór jest domyślny - nie najlepszy. Po prostu jakiś. Nie na tyle zły, żeby od razu aż paliło do szukania alternatywy - chociaż później może już palić. Poza tym o tym, co jest domyślne, a co nie niekoniecznie decydują kwestie techniczne - myślę że dużo więcej mają tu do powiedzenia chociażby naleciałości historyczne i statystyka, a te się lubią kumulować i dostawać korpo-boosty.
(...)
To, że do SQL też są pełnoprawne ORMy, narzędzia do automatycznych migracji, DSLe, LINQ już ustaliliśmy :P
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ć.
W świetle powyższego ten atut jest trochę wyolbrzymiony
Nic z tych rzeczy. Po pierwsze to że "ustaliliśmy" ORMy, LINQ itp. nic nie zmienia. Nadal musisz zarządzań w ten czy inny sposób chociażby aktualizacjami bazy danych. I nie uwierzę że nigdy nie zdażyło się że aplikacja Ci wywaliła na środowisku developerskim/testowym, bo np. schema bazy się zmieniła ale w wyniku jakiegoś błędu/przeoczenia kod nie itp. Jeśli komuś nic takiego się ani razu nie stało to śmiem twierdzić że nie pracował przy wystarczająco dużych aplikacjach/projektach.
To by oznaczało, że w kwestii rozwiązywania problemów z referencjami lecimy w wariant nr. 2 i jakoś je ogarniamy po stronie aplikacji - czyli w pewnej mierze ta potencjalna przewaga bierze nam w łeb?
Nie, z powodu wspomnianego przeze mnie kilkukrotnie innego podejścia do modelowania domeny. Dokładnie to samo, "luźne" podejście do referencji stosuje się np. w DDD i event sourcingu, a tam baza danych w zasadzie nie ma znaczenia (z perspektywy kodu domenowego).
A z tym poliglotycznym podejściem do baz nie jest potem trochę jak z poliglotycznym podejściem do języków programowania? Niby wszystko fajnie i elastycznie a potem trzeba to utrzymywać, no i w przypadku DB jeśli masz kilka baz do różnych celów to gdzieś musisz zdecydować, kiedy z której skorzystasz i w jakim celu, więc nagle baza przestaje być szczegółem i wjeżdża cała na biało na pierwszy plan.
Poliglotyczne podejście nie oznacza stosowania multum różnych baz danych, podobnie jak stosowanie mikroserwisów nie oznacza że każdy jest pisany w innej technologii. Można, ale to raczej rzadkość.
@scibi92:
Jeszcze należy dodać fakt że SQL jest znanym po prostu standardem i to łatwym w nauce. Po co sie uczyć jakiejś bazy NOSQL do reportowania skoro mam już ten SQL - i mogę go (z jakimś drobnymi różnicami ewentualnie) wykorzystać z 5 albo i więcej bazach danych, a wydajnośc jest pewnie podobna.
No ok, można mieć takie podejście. To trochę jak z tymi słynnymi klepaczami (bez obraźliwego wydźwięku), jeśli komuś jest wygodnie i nie chce opuszczać strefy komfortu to dla czego by nie. Osoby z takim podejściem mogą śmiało zignorować ten wątek, bo jak już wspomniałem stosowanie NoSQL wiąże się z nauką i przyswojeniem nowego sposobu myślenia.
Poza tym- wiem że zabrzmi to jak słaby PR- z takim podejście nie ma miejsca na innowację. Wbrew pozorom można sobie pozwalać na stosowanie innowacji, i wdrażanie ich na produkcji. Pracowałem nad projektem z początkowym budżetem 25 milionów dolarów (który później urósł jak to zwykle bywa), duży system ubezpieczeniowy. Wybór padł na zastosowanie event sourcingu- nikt w zespole wcześniej go nie używał produkcyjnie. Oczywiście był odpowiedni czas poświęcony na studium wykonalności, prototyp architektury itp. No i zdecydowane podejście- albo robimy to jak należy, zgodnie z powszechnymi praktykami, albo wcale. Da się? Zapewniam że się da. A przecież ktoś mógłby powiedzieć że stawka jest za wysoka aby nie używać czegoś co już wszystkim znane. Uprzedzając żartobliwe pytania- projekt nie padł- odniósł sukces i jest rozwijany do dziś ;)
NoSQL bym wykorzystał do dwóch rzeczy:
1)Wyszukiwanie tekstowe(jak Elastic Search)
2)Trzymanie takich rzeczy jak jakieś konfiguracje, czy niezależne struktury jsono-podobne. Jeśli np. jest jakaś oferta kupna czegoś edytowalna w CMS, albo np. opis książki to w takim przypadku NoSQL wydaje się senowniejszy
Tutaj trochę dziwne, bo z jednej strony sam wcześniej przyznałeś że za dużo nie wiesz na ten temat (wydawało mi się że jesteś chętny się nauczyć), a z drugiej piszesz co w jakim przypadku byś stosował.
No ja dla mnie to są całkiem sensowne argumenty. Skoro i tak sporo danych będzie musiało być złączonych pomiędzy dokumentami to w efekcie otrzymujemy model relacyjny tylko bez SQL.
W ogóle to coraz bardziej jestem przekonany że argument "używaj SQL to modelu relacyjnego, NoSQL tam gdzie nie ma relacji" jest przestarzały i w zasadzie dziś nie ważny. W zasadzie prawie każdy model domenowy da się obrać w ramy podejścia relacyjnego, lub też nie. Stąd tym bardziej moje przekonanie że- w myśl takiego założenia- lepiej zastosować to co szybsze i wygodniejsze w użytkowaniu na codzień. Oczywiście zakładając że ktoś poświęcił czas na naukę konkretnej technologii.
Sytuacja 2)
mamy NoSQL: trzeba robić potencjalnie update w kilku różnych dokumentach, jak zapomnimy ogarnąć jednej mamy niespójność
To jest w sprzeczności z tym co pisałem wcześniej, i de facto kompletnie ignoruje to co wielokrotnie podekreślałem. Chociażby to że bazy NoSQK (szczególnie dokumentowo) nie oznaczają że zawsze unikamy normalizacji. W przypadku który podałeś- czyli wiele encji potrzebujących dane innej encji- jak najbardziej zastosowało by się referencje.Trochę przykre że kompletnie pominąłeś to co wcześniej wyjaśniałem, tylko po to by napisać argument który jest zwyczajnie bezpodstawny. Właśnie to jest problem o którym pisałem- zabieranie się za jakąś technologię nie tak jak się powinno to robić. Pozwolę sobie zacytować samego siebie, bo kończy się to tak:
zrobimy po swojemu a nie jak należy, a później obwinimy technologię/wzorzec
@karolinaa
Wahałem się czy w ogóle odnieść się do Twojego postu. Po pierwsze nikogo nie obrażam- szanuję swoich rozmówców, szanuję ich czas ale i szanuję własny czas. Jeśli ktoś ignoruje to co piszę, czyta między wierszami i wstawia mi w usta słowa któych nie powiedziałem to oczywiście że wypomnę brak czytania ze zrozumieniem. To nie jest obraza. Ponadto dotyczyło to jednego użytkownika i zacytowane przez Ciebie moje wypowiedzi są wyrwane z kontekstu.
To nie jest prawidłowa logika - jak mam przeczytać z jakimkolwiek uznaniem twoje zdanie na temat NoSQL w momencie kiedy używasz tak nierzeczywistej logiki. Nie robisz promocji w ten sposób świetnym rozwiązaniom NoSQL.
Tak jak pisałem wcześniej- podałem konkretne argumenty dla tamtego użytkownika. W ogóle nie wiem o co Ci chodzi z "nierzeczywistą logiką", nie mówiąc już o tym że nie chcę niczemu ani nikomu robić promocji czy anty-promocji. Inna sprawa że w odpowiedzi do Twojego pierwszego postu napisałem merytoryczny (mam nadzieję) komentarz który zgrabnie pominęłaś, tylko po żeby zarzucić mi obrazę innych. Jeśli czujesz się urażona w zwykłej dyskusji na temat baz danych i myślisz że ktoś tu kogoś obraża (o czym pisałaś nawet w jednym z komentarzy na mikroblogu) to może być to przejaw tego że ktoś narusza Twoją strefę komfortu. Może warto zamiast iść w zaparte spróbować poznać temat na własną rękę. W ogóle to jest jakiś słaby żart że uważasz że ten wątek czy ja osobiście obrażają użytkowników baz SQL, tym bardziej że ja sam przez większość lat pracy jako programista używałem właśnie baz SQL i jestem przekonany że jeszcze nie raz przyjdzie mi ich użyć- czy to z wyboru czy też nie.
W ogóle paradoksem tutaj jest to że- jak napisałem na wstępie- z NoSQL korzystam dopiero od niecałych 2 lat, wcześniej znałem tylko SQL. Nie jestem więc jakimś wojownikiem próbującym narzucić innym swoją kocepcję. Postanowiłem tylko podzielić się własnym doświadczeniem, bo ku mojemu zaskoczeniu okazało się że faktycznie są inne rzeczy poza SQL, i faktycznie fajnie się w nich pracuje. Sam uświadomiłem sobie jak bardzo miałem ograniczone perspektywy. Traktowanie wszystkiego co napisałem w opozycji do tego co- w prypadku niektórych- jedyne znane jest więc niepotrzebne. Choć nie ukrywam że dziwi mnie to że tutaj na forum- gdzie przecież tak często można spotkać się z postami o rozwoju, poznawania nowych podejść i technologii- jest jednocześnie tak duży opór jeśli chodzi o SQL i NoSQL. Dziwi mnie tym bardziej że pojawia się ze strony osób które z bazami NoSQL mają małe lub żadne doświadczenie. Trochę tak jak- o czym wspomniałem w tym poście- ja nieznający FP miałbym stawiać stanowczy opór jak tylko ktoś zasugeruje że warto iść w FP. W dodatku pzekręcając argumenty przemawiające za FP, konceptulanie przebierając je w otoczkę OOP i na błędnych założeniach przedstawiać kontrargumenty. Oczywiście nic takiego bym nie robił, znając swoją małą wiedzę w dziedzinie FP. Naiwnie chyba liczyłem na podobne podejście, tym bardziej naiwnie że mały odzew w wątku z przed dwóch lat powinień dać mi jasny sygnał jako mało popularnym podejściem są tutaj bazy NoSQL.
Myślę że na tym można skończyć dyskusję bo faktycznie wszyscy zaczniemy "kręcić się w kółko". Kto chce to coś z tego tematu wyniesie, kto nie to nie. Ja jedynie mam nadzieję że chociaż część czytelników tego wątku zechce zgłębić bardziej temat.