Joe,
I think you're very wrong on this item:
<snip>
* No transactions
* No referantial integrity
* No Journalling
Most IBM midrange shops haven't needed these because their primary
purpose is to recover from a database or system crash, and these simply
don't happen on the System i. Back in the days when disk space and CPU
cycles were a premium, it was a huge benefit to not have to do these
things. Now, I guess there's less reason, but I appreciate the fact
that I don't have to do all the extra work entailed.
</snip>
System crashes do happen on the System i. Not very often, but they're
still there.
Can we agree to modify it to say "rarely" happen?
Based on rarely, (if ever, to coddle some), then I say the primary reason
for these features is not for a system crash. But to prevent things like:
- Orphaned children (items whose item class is not on file sort of stuff).
- data auditing
- data recovery from program errors or 'hand' maintenance.
- data protection from hand maintenance.
Yes, RI is required. Even if your applications are "written correctly".
Because as much as we'd like to force every one to use our stored
procedures to access data, but reserve the right for ourselves to access
the data directly, the other developers won't follow that double standard.
They have business needs, such as mergers and acquisitions, that may not
fit so well into the model. I'll grant you that last statement may be a
little conjecture.
I'd also seriously look at check constraints. I see dates that pass
conversion into true date fields. However I fail to believe that we have
any active employees that have a birth date back in the 1600's.
Rob Berendt
midrange.com
