I've been using MongoDb (mainly with Meteor) and for me, it has been a great way to mock up prototypes and proof of concepts quickly.I'm just wondering, after building the initial product, if your product is likely to grow and change, is it a good idea to stick with mongoDb?Cause it seems like with MongoDb, you need to know a lot about how you're going to use the data upfront. From my experience only, I seemed to constantly be trying to decide whether a datatype should be a document in its own right or a sub-document.Making it a document gives it flexibility, but if you have all your datatypes as documents, well then you pretty much just have an SQL database with foreign keys that have no foreign key constaints.Making it a subdocument makes things perform better whilst being convenient - you don't need to join tables (which you seem to have to do manually) - but the problem seems to be if you need to query that datatype outside the context of the parent, it's very hard. So for example, if I'm building a website with chatrooms, I might have two datatypes - chatrooms and textEntries.Chatroom will be its own document. But textEntries can either be a document in its own right or a subdocument within Chatroom.If I make TextEntries a document, then I would need to manually keep track of the relationship between chatroom and textEntries which defeats the purpose of using mongoDB at all.If I make TextEntries a subdocument, this will make things easier but what if later on, I have a new requirement where I want to search across all TextEntries in all chatrooms for a particular word? With a prototype, I know exactly what I'm building so these decisions tend to be based on just getting the product working. But longer term, I wouldn't know how or in what way I'm going to want to query the data so in light of that, would I be better off just moving to an SQL database?
Is MongoDB appropriate for systems that will be likely to change?
database design;mongodb