When an application is created which need to store data, an SQL database is used very often.
So did I in a lot of asp.net applications. The resulting applications have often an ORM like the entity framework and maybe a business layer.
So when such an application needs to be extended(let’s say you have to add a comment property to an object), you have to change/extend the database, then the ORM and the business layer and so on.
To deploy the changes you have to update the target database and the application. I know that things like code first and fluent can make this approach easier.
I tried mongodb, I only used the standard driver and I had to extend some objects and all I had to do was changing the code.
So it feels that such approaches are much easier to realize when using mongodb.
I don’t have much experience with larger applications an mongodb. I know that a SQL database or mongodb doesn’t fit for all needs and both have their pros and cons.
I want to know if my feeling is right, if yes I would choose rather choose mongodb than SQL database.
I find it makes things easier in initial development, but once you get to supporting production it makes things more difficult. Sure when the data model changes you just change your code, but what do you do with the data in Mongo that still uses the old format? You either have to write a data model update script pretty much like your SQL schema change script, or your application has to handle every version of the data model that has ever existed.
2
No, it is not easier to extend/change the application by choosing mongodb, because you still have a storage mechanism coupled to your logic. The choice just shuffles the deck, some changes become easier than a RDBMS, some become harder.
Furthermore, it may not be wise to select any storage mechanism based on the ability to extend/change the application, as this road may lead to:
-
Making a decision on data storage without an evaluation of the storage concerns (the question only lists development concerns).
-
Coupling the application to this choice, making it more difficult to change if the choice is not correct.
If your feature is that: “A user should be able to comment on an object”, then you may want to examine why the implementation would depend on where the object is stored. Shouldn’t this feature function the same way if the object is in memory, in a file, on the moon, or elsewhere?
All that is needed is a storage interface to the object and the comments. At that point, you can store the objects in memory to run tests, then choose to implement a RDBMS adapter, a noSQL adapter, both, or neither, based on storage needs and not necessarily development time.
1