Ashley, thanks for taking the time to answer so comprehensively. :-) Yes, and I acknowledge that I do tend to get a bit dogmatic about DRY. Fair point.
Your point regarding the ORM being at fault is a very good one, if you feel that constraints should be placed in the DB layer. Regarding when you came a cropper, isn't that what testing is for? Or did you have constraints on the testing database and not the live? 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. :-( So, there could be a case for having NO constraints on the test environment, and having constraints on the live. But this idea is almost certain to have every developer reading this shouting at the screen. And rightly. Purposefully making the test and live environments different is a deep and dark sin, and correctly so. So, we are back to a conclusion (on my part) that overall, constraints in the DB makes more harm than it makes good. I love your point about the data being more valuable, yes, that is very true. But no excuse for having shoddy AR:B because you can firewall the data away from damage with constraints. Disagree with DHH, sure! The minute we stop disagreeing about things, is the minute we stop advancing. Peter --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
