Hejka. Z reguły buduje swoje projekty na bazach relacyjnych, ale chciałbym jakoś konkretniej wykorzystać w praktyce także te nosqlowe. Wybór padł na Mongo, gdyz juz kiedys korzystałem z niej w jakichś drobnych projektach. Rzecz w tym, że zawsze, ale to zawsze zaczynają mi się układać w głowie relacje, które mógłbym zaimplementować do bazy. Jak rozumiem mija się to z celem i powołaniem takich baz. Zacząłem się zastanawiać więc, jakie przypadki czerpią garściami z nierelacyjnego modelu?
0
0
Wygląda na to, że rzadko spotykane :-)
0
No ale jednak relatywnie często (lub mówiąc trafniej, raczej nierzadko) gdzieniegdzie obijają mi się o uszy dyskusje właśnie na temat np. Mongo i planach wdrożenia go w projekcie XYZ. Tak więc muszą istnieć okoliczności, które doskonale sprzyjają wdrożeniu tego systemu.
1
A może to jest kwestia mody? Kiedyś sam się zastanawiałem nad tym problemem, który Ty podrzuciłeś i doszedłem do wniosku, że nic mi takiego do głowy nie przychodzi.
Podejrzewam, że duża część osób po prostu usłyszała, że jest takie coś, że to teraz jest modne i za wszelką cenę chcą z tego skorzystać, nawet jeśli nie ma to większego sensu. Typowy przykład cargo kult. Zgodnie z zasadą, że jak masz w dłoni młotek, to wszystko nagle staje się gwoździem ;) Oczywiście - nie twierdzę, że płaskie bazy są bezużyteczne, ale jakoś sam (podobnie do @Belka) nie kojarzę sytuacji, w których ich zastosowanie by dało realne korzyści.
3
disclaimer: nie korzystałem z mongo zbyt dużo
Dlaczego cargo, a nie np. wygoda i niski entry level?
Chcąc nie chcąc bazy relacyjne są niełatwe. Stoi za nimi dużo teorii, wymagają znajomości SQLa, nie pozwalają łatwo robić głupot kurła dlaczego nie mogę tego usunąć, jaki znów kaskejd dilit?
Nie trzeba spędzić tygodnia na konfigurowaniu relacji i zależności, a jeżeli coś pójdzie nie tak, to przecież mamy elastyczność, czyż nie?
Nie żebym promował, lecz chyba rozumiem dlaczego niektórzy wolą np. Mongo.
5
Pracowałem 2 dwóch projektach gdzie było Mongo, w jednym lead dev właśnie kończył przepisywać do Postgresa bo wszyscy narzekali na Mongo, drugi umierał więc nikomu się nie chciało przepisywać choć wszyscy narzekali na Mongo. Na reddicie też widziałem pełno wątków od ludzi, którzy narzekali na Mongo i przepisywali projekty na normalne (czytaj: relacyjne) bazy. Osobiście nie dziwie im się - ta składnia zapytań z użyciem JS to jakaś chora patologia. Ogółem masa hipsterów chciała być trendy i wskoczyła w nowe NoSQL-e, bo nowoczesne i ach, nie trzeba schemy, po czym po latach odbijało się to czkawką. Nagle się też okazywało, że schema ma sens.
Ogółem zatem, do czego można by użyć mongo? W innym projekcie, w którym byłem był zamysł, by cache'ować nim niektóre JSON-y. I na tym w sumie pomysły mi się kończą. Do innych zagadnień są ciekawsze technologie.
Relevant
4
NoSql dokumentowe bazy danych się sprawdzają zwykle tam gdzie jest duża skala/ostateczna spójność/duży rozmiar danych(> 1TB) przy czym zwykle jest to też nieskomplikowana domena. Większość projektów jednak nie ma takich problemów, dopiero jak nam nie starcza pojedynczy serwer sql do zapisów z kilkoma replikami do odczytów + sensownym cachem, czyli kiedy nie jesteśmy w stanie skalować bardziej serwera sql, wtedy bazy dokumentowe NoSql zaczynają mieć sens.
Trochę inaczej ma się sytuacja z wyspecjalizowanymi bazami NoSql: grafowymi, kolumnowymi, klucz wartość, które mogą się nam przydać do rozwiązania konkretnego problemu, natomiast w zastosowaniu "do wszystkiego" patrz wyżej.
Natomiast bazy relacyjne powoli zaczynają oferować to co oferują wyspecjalizowane bazy nosql, np SQL Server w najnowszej wersji ma wsparcie dla grafów (zgapione z nosql grafowe), ma tabele zoptymalizowane do trzymania wyłącznie w pamięci (zgapione z nosql klucz wartość do implementacji cache), ma indeksy kolumnowe(zgapione z nosql kolumnowe).