Re: Which of the SYSIBM tables/views show the row count for

rob@xxxxxxxxx wrote:

Joe,
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.

If, you crash once every five years, is it necessary to add additional system complexity? Or is going to yesterday's backup tape good enough? It's a business decision.

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.

We've hashed this out over and over. If you have programmers going at your database and screwing it up, you need new programmers. The real concern is unfettered ODBC access. If you allow updates via ODBC, you probably need all of the above: RI, constraints, and so on, as well as exit programs and audits and logs and every other darned thing, because your database is an accident waiting to happen.

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.

So why didn't your maintenance program pick this up?

This also is opinion so it's time for me to get out. If in your shop you have developers who regularly screw up the production database, then perhaps you need all those things. To me, it's another business decision. I know shops where programmers aren't allowed to touch the production database and there's no outside access, so it really is only the application program. It's all a matter of your corporate philosophy.

Joe