> So, unless you're already very clear on what your exact use case is going why the spend time analysing before even getting your project off the ground?
Because if you don't know what you want you are almost guaranteed to pick the wrong technology.
Because if you don't know what you want you are almost guaranteed to pick the wrong technology.
That's one way to look at it...but a bit shortsighted.
Requirements can and do change, and a well designed model in an RDBMS will be far more extensible than a similar one in NoSQL document store. So RDBMS' aren't the "wrong" technology, they the safest bet; not to mention most modern relational DBs already out-perform mongo, so the point is sort of moot anyway.
Because that sounds like magic.
Also MongoDB destroys any RDBMS (minimum 10x faster) if you have embedded structures instead of joining against 10 tables in a normalised design. Hence the importance of understanding your query patterns and domain before selecting the database.
Real world example: Consider an Order table and a Visit table; conversion rates aggregate orders over visits. In Mongo you can denormalize some of the Visit data into Order, but what happens when you change the logic for computing conversion ratios? Or you want conversion ratios broken down by web browser, source tag, or any of the other data elements that live in Visit but you didn't denormalize ahead of time?