Hi NWRUG, On 10 Oct 2008, at 08:27, Peter Morris wrote: > Which brings up a valuable point, constraints in the DB can mask > problems at the orm/model layer > and this breaks the principle of 'fail early'. Yes, another > principle. :-( >
Really? I'd have thought the exact opposite: constraints can highlight problems in the domain(/model) layer - failing early rather than allowing data integrity issues. The constraints are duplication, but duplication with _some_ value. Rather like double-entry book keeping - a mistake on one side is caught by the duplication on the other. I think database constraints are very like static typing - if you take the type-checking away the behaviour of a system written in a statically typed language shouldn't change; neither should the behaviour change if you disable DB constraints. If they have any value - they are as a double-check. In the same way that TDD reduces the value of static typing, TDD also reduces the value of constraints. Whether it reduces the value to be less than the cost depends on you and your system's relationship with the database. If the DB belongs entirely to your Test Driven app - ie it's just the persistence layer for your domain objects - then the DB constraints are much less value than if you're sharing the database with different applications. BTW what if the db constraints could be generated from the model? That would be an interesting option. ---------------- Paul Wilson http://merecomplexities.com Scotland on Rails 26-28 March 2009 http://scotlandonrails.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "NWRUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/nwrug-members?hl=en -~----------~----~----~----~------~----~------~--~---
