4

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.

3

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
    Wait, what? How are either of those two "drawbacks" different for conventional relational stores? Are you sure they even exist? You can control projection in Mongo just as easily as in relational DBs and of course you HAVE to write a schema upgrade script with SIGNIFICANTLY greater downside in most relational stores. For example many relational stores require an exclusive table lock when adding or removing a column. – RibaldEddie Nov 1 '13 at 22:02
  • Not sure which two drawbacks you mean, I only list one. Which is, how do you deal with production schema changes when you don't have a firm schema? As I see it, you have two options one is to write a schema migration which puts you on par or a little worse than Relational DBs, or you take the hard path and handle all schema variations in code. – stonemetal Nov 4 '13 at 19:31
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
    "some changes become easier than a RDBMS, some become harder." Could you please say more about which changes become easier and which become harder? – user16764 Nov 2 '13 at 0:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.