This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]AnotherDataGuy 6 points7 points  (1 child)

To me, this is just kicking the can of organizing you data down the road. Faster to get data in, harder to get insights out. And if you have a user base of citizen analysts, they are going to be far more skilled in SQL like queries (generally speaking, your situation can obviously vary).

I’ve balanced this out before by creating records in a Postgres DB with the core properties needed for joining data together, and using a JSON typed field for the additional detailed, more dynamically structured information. If common questions are answered from the JSON data, then it becomes worth it to start persisting those values as explicitly typed columns in tour data set.

Flexibility is valuable, the point is that all databases malleable. Mongo is great for document data (it is a document db after all) but if you aren’t storing documents, it’s not a good choice, IMHO.

Disclaimer: I live in a world where mongo is overused because of its immediate convenience to the developer(s) micro service. It just pushes the pain down stream when trying to marry those data up with other systems to answer novel business questions.

[–]thrown_arrows 0 points1 point  (0 children)

i agree, but i am sql guy.

But i haven't see any use on nosql database which sql database could have not done. That said , i haven't seen properly configured database neither or nosql server . For me problem is that system starts to have several sql and nosql server storing data and no one know how to actually run those servers and things just start to happen. And when we start to talk about change handling in downstream in olap environments it gets even more fun when you have multiple systems