Validation is vital but the datastore is not the place to do it, because handling invalid data by dropping it on the floor is almost never the right behaviour.
There is no substitute for actually understanding your data model, but once you do 99% of the time you'll find using an RDBMS comes with minimal benefits and significant costs.
That being said, if your code doesn't catch and handle errors, then there's a couple of deeper problems already.
Well if you can't get input that violates that integrity then what are you gaining by enforcing that integrity?
> That being said, if your code doesn't catch and handle errors, then there's a couple of deeper problems already.
Sure, but how can you do error handling without data storage, given that your application itself is stateless? Maybe you retry the failure a few times, but ultimately your only option is to drop the data on the floor, which is almost always not what you want.
Fixing up data that was written wrongly takes work, there's no getting away from that. But if you have a record of the original write attempt then at least you can do that work and recover the data (if you decide the cost/benefit is worth it). Whereas if you have the datastore reject it at write time then you're SOL before you've even started.
Have you ever actually encountered any RDBMS that just silently "drops" your write without informing you, or is this just how you think they work?
Otherwise, isn't this just like any other data write erroring out -- MongoDB driver saying "Service down!", simple flat-file write saying "Disk full!", etc -- in that if your app doesn't react to this, it's not the data store but your code that sucks?
Perhaps I'm wording this badly?
Your application should _not_ be generating data which can't go into the database correctly. If it is, that's a different set of problems. ;)