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

DeLong, Eric wrote:

Say what? ;)

Joe, I'm sorry, but the "adds overhead" argument is ridiculous... Your premise is that your program code (written in a HLL, presumably) can determine uniqueness faster than a UNIQUE constraint can.... I would think that most actions like this would involve, at a minimum, a SETLL/IF %equal() block to determine uniqueness. Would that REALLY be faster than DB2 signaling a constraint violation?

"Ridiculous" is an interesting term to use without facts and of course immediately got my hackles up. But let's dismiss the word and concentrate on the issue. Actually, my premise is simply that writes to a database with UNIQUE constraint, either using DDS or DDL, are far slower that writes without. As it turns out the reality is that for some reason physical files without UNIQUE are faster than all of the other keyed methods: keyed physical with UNIQUE, logical with OR without UNIQUE, and DDL of any kind.

As to the SETLL/IF, as opposed to the constraint, I believe Barbara weighed in on that a long time ago: using a SETLL is much faster than the constraint, because that actually raises an exception, one of the more expensive things in the ILE spectrum.

As in most of these discussions, so much of the rhetoric is based on outdated notions. We have to UNlearn as readily as learn.

Okay, my hackles are up again. Did you even read any of the posts? My opinions are based on benchmarks. Exactly what are yours based on?

You presume that its better for the developer to control such activity,

Better? It depends on your philosophy. I simply said it was faster. It's a philosophy thing.

yet for the case of database integrity, where one would hope that such activities ALWAYS should occur, you're willing to trust that all developers will do it correctly.

Why, yes, I do. But you see, I come from a background where professional programmers were expected to program professionally: they followed standards, and understood what they were doing. If mechanics were as undisciplined as you seem to think programmers are, we'd be seeing wheels fall off on the expressway every 30 seconds or so.

IMO, if there's a way to enforce these data integrity rules globally, and that eliminates the ability to "forget about it", then there's no contest. Of course, the developer still needs the appropriate error handlers in place, but that's handling just the exceptions.

There is a way. You encapsulate data access in server programs. It's really not that hard, and it allows you to haev complete control over the data as well as enforcing complex business rules that are beyond the capability of triggers and constraints, while at the same time allowing professional programmers to work without the overhead of unnecessary overhead. In fact, in this age of ILE and service programs, what's really bizarre to me is to allow people direct access to your database!

It really is an opinion. It basically depends on your opinion of programmers. Mine happens to be very high, but then again in my career I've either hired the folks that did the work or did it myself, so I take full responsibility for the quality of the code (and no small sense of pride).

Anyway, enough. This is now officially in the land of "opinion-slanted debate" and it's where I get out of the pool...

Joe