> background Web dev for some years, then data science. > implies shutting everything down That's what "loudly" implied to me. Loud means crash, no? > basic

> background Web dev for some years, then data science. > implies shutting everything down That's what "loudly" implied to me. Loud means crash, no? > basic assumptions of soundness I like to enforce that at the application layer, so that I can quickly swap storage without worrying. Whether I'm writing to database or a mock object, I'd hope the exceptions that arise in the application are the same. Things like unique index are easy to implement with a mock object, but more complex constraints I'd rather enforce in code that I find easier to read. > buggy or broken All I'm saying is not to be an absolutist. Some things are good to have as database constraints, others are good as application logic. I'm arguing against the idea that "validations are [never] enough." In contrast, database constraints are almost never enough to manage the complexity of data integrity.