Jim C. Nasby wrote:
>>No, I don't agree with this. Too many people waste time designing for
>>"what if..." scenarios that never happen. You don't want to be dumb and
>>design something that locks out a foreseeable and likely future need, but
>>referential integrity doesn't meet this criterion. There's nothing to keep
>>you from changing from app-managed to database-managed referential
>>integrity if your needs change.
>
> In this case your argument makes no sense, because you will spend far
> more time re-creating RI capability inside an application than if you
> just use what the database offers natively.
But one of the specific conditions in my original response was, "You have application-specific knowledge about when you
canskip referential integrity and thereby greatly improve performance." If you can't do that, I agree with you.
Anyway, this discussion is probably going on too long, and I'm partly to blame. I think we all agree that in almost
allsituations, using the database to do referential integrity is the right choice, and that you should only violate
thisrule if you have a really, really good reason, and you've thought out the implications carefully, and you know you
mayhave to pay a steep price later if your requirements change.
Craig
