| I often read that argument that NoSQL Databases are Schemaless and yes the Database is but your Data is or it isn't. YOU must know your Data. "All the while moving work onto the developers to standardize how they handle different migration cases." I know a startup is fast and bla bla...
BUT your team should know the tools that you are using...
For me SQL DB's force me to add a new field and some kind of value and i don't like to be forced to a solution. "In document stores, you have two choices: store related data as sub-documents, or store related data as separate documents with references. It is up to the developers to understand the trade-offs of both approaches. Selecting one over the other can lead to performance gains or issues, scalability issues and above all, make asking certain questions of the data a lot harder." Again know the tools you are using.
And for example MongoDB has good ORM's too. "But that takes much more forethought and is dependent on a particular problem." If your startup is doing something new and shiny you don't have the knowledge and forethought and you often dont know what particular problem will come at you. Most of the point's look like:
You learned at your University SQL now you know it(but in really life you don't) and now use it because you know how to normalize a Database. This argumentation is often used to say why java is so great or why javascript is bad. I personally started with php then moved to rails and now to meteor(uses MongoDB) and we never before meteor could make so fast a good prototype which for a startup is very important. So yeah if you are comfy with SQL use it if your comfy with NoSQL use it. |