I'll give you a practical scenario that I encountered where MongoDB could have done good and saved a lot of operations. But sadly, MongoDB failed to provide the best solution, letting SQL win.
If I delete the cart, I would want the User to be deleted from the Products array of "all Users who have it in their Cart". To do so, I need to pupulate User with Products, get product Id, then search Products to find the product with the ProductId and then delete the user from its array of "all Users who have it in their Cart".
MongoDB could have allowed multi-level population and could have allowed modifying sub-documents. Would have saved a lot of CPU usage.
MongoDB, please address these issues and beat SQL. No point in defending with the lame, we are non-relational. Databases are mostly relational.
Scenario 1
User has Cart with Products. Products has "all Users who have it in their Cart".If I delete the cart, I would want the User to be deleted from the Products array of "all Users who have it in their Cart". To do so, I need to pupulate User with Products, get product Id, then search Products to find the product with the ProductId and then delete the user from its array of "all Users who have it in their Cart".
MongoDB could have allowed multi-level population and could have allowed modifying sub-documents. Would have saved a lot of CPU usage.
Scenario 2
I am of the thought that optional cascading should be allowed in MongoDB, just like in SQL. Would save a lot of unnecessary logic which can be handled by MongoDB automatically. Most of the time the scenarios are such where when one document is deleted, its reference in other documents of other collection should be deleted too.MongoDB, please address these issues and beat SQL. No point in defending with the lame, we are non-relational. Databases are mostly relational.
Comments
Post a Comment