3 ms·
It has to be noted that a lot of the >referential< constraints are just necessary because an RDBMS wants you to split your "object" over several tables. What I
by rb2k_ 15y ago
It has to be noted that a lot of the >referential< constraints are just necessary because an RDBMS wants you to split your "object" over several tables. What I found pleasant with the non-relational databases is that these constraints CAN just fall away because you e.g. nest "comments" inside of an array in a "blogpost" object. When deleting the blogpost all comments will be deleted too and cascading deletes are just not necessary.
Some of the other constraints you'll have to implement in your software. The advantage: you don't put application logic outside of your application. The disadvantage: Every bit of code touching that value has to know the limitations.
I wonder if this could be solved by using a message queue and just have dedicated step for updating/deleting data
- jeltz 15y agoOne of the messier parts of having to implement referrential constraints in the application is that you have to handle the concurrency issues yourself. A RDBMS handles the locking of the referred rows for you.
- zzzeek 15y ago> I wonder if this could be solved by using a message queue and just have dedicated step for updating/deleting data See but now you're building some big thing. Let's just include that in MongoDB or whatever, a "constraints engine". So that you don't have to build it from scratch each time, and can have some mature, well tested thing instead of something ad-hoc and probably buggy. Now you need to carefully build migrations again !