[trevoz]

Jezuu przypomniało mi się jak kiedyś był hype na NoSQLowe bazy danych, głównie MongoDB.

Dobrze, że ludzie wrócili po rozum do głowy i kapnęli się, że nierelacyjna baza danych nie nadaje się do większości rzeczy.
Ale dalej śmieszy jak człowiek wraca do jakiegoś starego projektu z MongoDB, gdzie okazywało się że bez joinów to jednak ciężko coś zaprojektować, więc tworzyli relacje w nierelacyjnej bazie danych xd

#programowanie #programista15k #bazydanych #sql #nosql #mongodb

[DoloremIpsum]

@trevoz .

[Brother_of_Steel]

@trevoz: wiesz, pal licho jak zrobili te "relacje", gorzej jak #!$%@? wszystko do jednej encji, bo nie ma relacji xD

[trevoz]

@Brother_of_Steel: ano, jeszcze gorzej, najlepiej gdy bez jednolitej schemy bo nie trzeba ( ͡° ͜ʖ ͡°)

[kobrys13]

@trevoz: Ja tam się nie znam bo tylko architektem jestem, ale taki Comos DB w Azure do odpowiednich problemów (nie do wszystkiego) to generalnie zajebisty jest :)

[Saly]

@trevoz: inna sprawa, że ludzie używali mongo bo nie chcieli się bawić w relacje tylko włożyć jsona do bazy i elo. Na szczęście teraz bazy SQLowe wspierają takie mechanizmy, więc jeden argument odpada

[zibizz1]

@trevoz: A kiedykolwiek myśleli że nadaje się do większości rzeczy? Po co relacje, można trzymać kopie danych jest wydajniej :)

[Saly]

@kobrys13: jaką masz intuicję odnośnie użycia cosmosdb vs relacyjne? Ostatnio myślałem sobie o projekcie w pracy, który używa dynamodb (cosmo to chyba analogiczna baza?) i odniosłem wrażenie, że strasznie to upierdliwe. Rozumiem, że ma to zastosowanie przy ekstremalnych warunkach, ale większość projektów (zwłaszcza tych nowych) nie operuje na takiej skali, żeby było warto

[pieczony-ziemniaczek]

@trevoz: Przez chwilę w komercyjnym projekcie w mojej pracy bawiłem się mongoDB i byłem zachwycony bo z zerową wiedzą szybko się połapałem o co chodzi. To był początkowy etap projektu, zostałem przerzucony do pracy w innym, a ludzie którzy dalej tkwili w mongoDB w tamtym projekcie, wraz z jego rozwojem zaczęli płakać, że ta baza się dla ich zastosowania totalnie nie nadaje.

[Brother_of_Steel]

wraz z jego rozwojem zaczęli płakać, że ta baza się dla ich zastosowania totalnie nie nadaje.

@pieczony-ziemniaczek: typowy głupio rozumiany agile jest typowy.

[kobrys13]

wraz z jego rozwojem zaczęli płakać, że ta baza się dla ich zastosowania totalnie nie nadaje.

@pieczony-ziemniaczek: reafctoring?

W początkowych fazach projektu też nie pisze się skalowalnych serwisów i miliarda domen DDD. Do tego przychodzi się z czasem i budżetem :-)

[Campell]

@Saly: o panie wolę chyba mieć ogromny dokument niż jeszcze raz wrzucać jsona do psql. Albo co gorsza w oparciu o dane z niego jakiś raport generować. Never again

[Saly]

@Campell: chyba nie rozumiem, czy różni się "ogromny dokument" od jsona?

[mjr_bien]

@trevoz: obowiązkowo przypominam:

[fujiyama]

@trevoz: RavenDB, Couchbase - nosql + transakcje, joiny, replikacja/praca w klastrze - wszystko darmo do 4 węzłów.
O bazach chmurowych nie wspomnę.
O rozwiązaniach typu Aerospike, Scylla, które są w stanie zrealizować do 1mln transakcji na sekundę też już nie piszę.

Postgres to nie jest ani cud techniki ani wydajności...( ͡° ͜ʖ ͡°)

[swagerstom]

bez joinów to jednak ciężko coś zaprojektować

@trevoz: nosqlowe nie służą do robienia relacji, tylko wrzucania dokumentów o różnych, ale niektórych współdzielonych, propertisach do jednej, wielkiej kolekcji, a następnie umiejętnego ich filtrowania po tych propertisach.

[zibizz1]

@trevoz: Jeśli ktoś nie działał to proponuje zerknąć na bazę Firestore w Firebase. Ma ona swoje ograniczenia np brak textsearch czy ograniczona ilość zapisów per dokument/sekundę. Ale do małych projektów które mogą się w przyszłości łatwo skalować jest świetna. Całą aplikację można napisać na kliencie i pisać bezpośrednio do bazy. Nie mamy tez problemu z odświeżaniem bo gdy otwieramy okienko w aplikacji to robimy query do bazy i nasł#!$%@? na zmianę

[WielkiElektronig]

@trevoz czasem się przydaje

[Ignas1415]

@trevoz: problem w tym że relacyjne bazy danych są bardzo słabo skalowalne a w tym jest korzyść. Poza tym drugim dużym minusem to koszty utrzymania.

[Ignas1415]

@kobrys13: czyli najpierw robicie wielki monolit a potem dopiero refactoring na DDD? Finansowo DDD wychodzi nawet korzystniej. Właśnie trzeba od początku dobrze zaprojektować a nie potem się pakować w refactoring...

[uxie]

U mnie w pracy sporo rzeczy przenosimy z mysql na dynamo.
Głównie po to by oszczędzić i zapewnić większą dostępność.
Z mysqlem jest ten problem, że ciężko się to skaluje. Albo przez większość czasu przepłacasz albo klękasz jak dostajesz 10x więcej requestów niż zazwyczaj.