5 ms·

What is your software development background? I ask because it would not have once occurred to me in the past fifteen years of software development that “enfor

What is your software development background? I ask because it would not have once occurred to me in the past fifteen years of software development that “enforcing database constraints” in any way implies shutting everything down and stopping transactions until the cause of a violation is rooted out. If you’re approaching it from the position of collecting raw data from sensors or something, that might make sense. But from the perspective of a webapp, allowing duplicate (or empty) usernames or failing to keep foreign key relations valid often violate basic assumptions of soundness that the application is based upon. In these cases, the right answer is to drop the data on the floor (loudly) so a developer can look at it. Inconveniencing a customer once here is infinitely better than inconveniencing them constantly due to the site being buggy or broken as a result of the invalid data, and prevents needing to migrate the data in the future which can actually be impossible to do correctly in some cases.

xapata 9y ago
> 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.
- mixmastamyk 9y ago
  App should not crash but return/log the database error, ideally translated to layman terms on the customer end. Logs sent high priority to dev team for fixing.
  - xapata 9y ago
    Indeed, I agree.

xapata 9y ago

> 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.

mixmastamyk 9y ago
App should not crash but return/log the database error, ideally translated to layman terms on the customer end. Logs sent high priority to dev team for fixing.
- xapata 9y ago
  Indeed, I agree.