I have mainly worked on RDBMS databases. Recently studied MongoDB and liked where we don't have to define schemas upfront. So application developers straightaway can start writing the code. Major drawback that is stated in most of the articles is that MongoDB(or any other document based DB) is not good for transactional requirement. I am wondering why its not good for transactions. Just trying to understand with the help of use case we have in any web application
Consider a use case where we have user profile page with multiple addresses like primary, secondary and mailing address.User can have multiple bank accounts. In RDBMS we will create below tables
- User(Table user_profile)
- Address(foreign key pointing to user table)
User and address are created in one transaction but both address and user creation should be atomic.
- Account (foreign key pointing to user table)
With MongoDb there will be single User
JSON document containing array of address and array of accounts. So my understnading is there is no need of transactions in mongodb
at the very first place in many places because it will store all user related stuff in single document . But yes in some cases where transaction is happening across users
then we will be needing transaction like account transfer from one account to another account.
So the way documents are stored in MongoDB, most of the places where transactions are needed will be eliminated. Is n't it ? If yes is there a way where we can maintain transaction across documents also probably through two phase commit ?
I see a good reason to use mongodb or any other document based DB even for applications which requires transactions in RDBMS but MongoDB eliminates the need of transaction itself except where transaction is required across document. Using document based DB will provide the advantage of faster development, better fetch and update calls.
Let me know if understanding is correct ?
Update :-
Other plus of Mongo I see are :-
Joins are not required so better performance and less complex queries.
Read/write throughput is better in mongo(I haven't tried it myself just stating from advocates of document stores)
If for particular document I need to store some extra information(say I want to store comment field for specific types of document) I don't have to add column for all documents,
It stores the data in json form
Eliminates the need for transactions in most of the places like the example I stated above because it stores all connected information in single document itself
Cons
The biggest and only con I see is not able to support transaction across documents which most of the web applications are required at some point of time though numbers can be few. We need to resort to techniques like two phase commit in those cases.
Also I agree the statement So application developers straightaway can start writing the code
can be boon or bane depending on situation. In RDBMS , its kind of we make the policy , review it upfront and then every one follow it. If we want to change that policy, its bit difficult. In Mongo like DB, you don't have policy in place, but you have to decide some informal contract and rely that every one follow it. Obviously there are chances here that it can be misused , so it(application code) has to be reviewed more often to confirm the contract we decided upon and if for some reason we want to change contract its much easy to incorporate here
Joins are not required in relational databases either
. Consider I have user name and I want to find his address. I need joins. ` 2.It stores data in json form?
Now in ajax world most of communication happens in json. Now , I see it consistent across the layers where developers does not have to struggle with different data representations 3.Eliminates the need for transactions ?
well everything in world has cost. What I meant was it depends upon the scenario but just saying mongo does not support the transaction is not minus