[michal_szn]

Gdybyscie w dniu dzisiejszym rozpoczynali pisanie systemu CRM dla firmy logistycznej, to na czym oparlibyscie baze danych ?

a) tradycyjnie jakas relacyjna typu MySQL albo Postgresql
b) cos NoSQL'owego, moze MongoDB

Wiadomo, ze do tego typu oprogoramowania to bardziej pasuja relacyjne bazy danych, ale jednak uzywajac jakis NoSQL'ow, mozna obnizyc koszty...
(Chyba, ze cos sie zmienilo)

#programowanie #sql #mongodb #nosql

[Qrystus]

Jak chcesz obniżać koszta skoro Postgresql jest darmowy. Zwróć uwagę, ze do rdbms jest więcej specjalistów niż do nosql

[p.....9]

@michal_szn: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
Tyle w temacie

[michal_szn]

@Qrystus: hmmm no zawsze myślałem, ze wraz ze wzrostem wielkości bazy danych to w przypadku relacyjnych koszty zaczynaja być większe
Dlatego pisałem „no chyba ze coś się zmieniło”

[k.....e]

@michal_szn: to architektura aplikacji dyktuje narzędzia a nie narzędzia architekturę. Wybierz taka bazę jaka pasuje do twojego modelu danych

[wolnynajmita]

2013/11/11

@plan_9: Artykuł sprzed prawie sześciu lat ( ͡° ͜ʖ ͡°)

[xetrov]

systemu CRM dla firmy logistycznej

b) cos NoSQL'owego, moze MongoDB

@michal_szn: he he he ( ͡° ͜ʖ ͡°)

Pewnie będziesz miał tam miejsce dla jakiegoś Redisa (bo po co Mongo) ale postawiłbym sporo że niczego lepszego od Postgresa nie znajdziesz na podstawową bazę.

[p.....9]

Artykuł sprzed prawie sześciu lat ( ͡° ͜ʖ ͡°)

@wolnynajmita: Artykuł jest dalej aktualny, polecam przeczytać cały.

[Koliat]

@plan_9: super lektura, dzięki :)

[wolnynajmita]

@plan_9: Czytałem, czytałem, nie pierwszy raz się na niego natknąłem. I nie zgodzę się:

Po pierwsze: od tamtego czasu Mongo się bardzo rozwinęło (że tylko wspomnę: w 4.0 pojawiła się np. multi-document transactions)

Po drugie: dużo w tym artykule demagogii:

The only thing it’s good at is storing arbitrary pieces of JSON. “Arbitrary,” in this context, means that you don’t care at all what’s inside that JSON. You don’t even look.

[plushy]

@michal_szn na mongo nice oszczędzisz, co innego jeśli użyjesz jakieś usługi typu DynamoDB ale na tym możesz też stracić

[j.....p]

@michal_szn: u nas sa jakies niemieckie SAPy, nie trzeba nowego pisac sa juz gotowe

[ciachostko]

@michal_szn: musisz odpowiedzieć sobie na jedno zajebiście ważne pytanie, czy istotne dla tego systemu jest to, czy ma obsługiwać transakcje, czy dane mają tam wpadać bez weryfikacji czy to się udało. Moim zdaniem powinna być taka weryfikacja więc NoSQL odpada.

[macrusher]

@ciachostko ale Mongo ma zarówno transakcje jak i weryfikacje czy się udało. Czemu więc odpada?

[ciachostko]

@macrusher: owszem ma ale wtedy spada wydajność całej bazy więc podstawowa cecha dla której wykorzystywana jest ta baza zostaje niwelowana. Niech mnie ktoś poprawi jeśli się mylę.

In most cases, multi-document transaction incurs a greater performance cost over single document writes, and the availability of multi-document transaction should not be a replacement for effective schema design.

[Hauleth]

@macrusher bo jeśli chcesz zachować te „super wyniki” z benchmarków przeciwko Postgresowi to te transakcje o kant rzyci (źródło). Dodatkowo OP przejmuje się rzeczą, która zapewne nigdy go nie będzie dotyczyć, a mianowicie - co się stanie jak wyrośnie z RDBMS. No to moja odpowiedź jest taka, że nie wyrośnie, zwłaszcza z Postgresa. Już pomijając fakt, że dokumentowe DB mają bardzo wąskie zastosowania, a jak potrzebujesz, to Postgresa też można

[M.....k]

@michal_szn: No i pomijając te wszystkie sugestie jakie dostałeś warto rozważyć jak duży jest to system i ile osób będzie nad nim pracować. Jeśli jest to mały CRM który będziesz programował tylko Ty, chcesz skończyć to szybko i zapomnieć to użyj po prostu MySQL/Postgres, jakiś dobry ORM i framework bez zgłębiania się w szczegóły. Jeśli to CRM na którym będzie pracować do kilkudziesięciu osób to wybór bazy danych nie ma wielkiego

[macrusher]

@ciachostko: @Hauleth: Ale ja nic nie wspominam o super wydajności. Prostuję jedynie niepoprawne informacje które są bardzo popularne w internecie jakoby Mongo nie miało transakcji


Ale już trzymając się tego tematu spadku wydajności, używać transakcji można per query, nic nie stoi na przeszkodzie żeby w krytycznych elementach gdzie jest wysoki throughput ich nie robić (bo często w tej sytuacji nie jest to niezbędne, ale wiadomo to zależy od przypadku użycia,

[v.....i]

@macrusher: to jak jest z teraz z tym nowym mongo? W starej wersji chyba celowo nie było transakcji, aby wszystko wykonywało się szybciej od baz relacyjnych. Jak wyglądają teraz transakcje w mongo?

[Hauleth]

@jaksiepatrzy: bazy NoSQL oczywiście, że nie pozwalają budować relacji, dla tego po polsku nazywa się je "nierelacyjnymi bazami danych". Przy czym przez relację trzeba tutaj rozumieć oryginalne pojęcie pod tym terminem, a nie JOINy, które ludzie teraz traktują jako "relacyjność".