Jim C. Nasby wrote:
1. You have only one application that modifies the data. (Otherwise, you
have to duplicate the rules across many applications, leading to a
code-maintenance nightmare).
You forgot something:
1a: You know that there will never, ever, ever, ever, be any other
application that wants to talk to the database.
I know tons of people that get burned because they go with something
that's "good enough for now", and then regret that decision for years to
come.
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.
Design for your current requirements.
Let us be of good cheer, remembering that the misfortunes hardest to bear are
those which never happen. - James Russell Lowell (1819-1891)
Therefore do not be anxious about tomorrow, for tomorrow will be anxious for
itself. Let the day's own trouble be sufficient for the day.
- Matthew 6:34
Craig
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
