Re: time/date as key fields

On 11/20/10 7:23 AM, dieter.bender@xxxxxxxxxxxx wrote:

... seems to be pure marketing to me, I didn't find any
documentation, how it works and about measurable benefits...

Birgitta Hauser wrote on Saturday, November 20, 2010 3:24 PM:

What about "constraint awareness", a technology that checks
constraints and handles them in a special way?
Check constraint awareness and RI awareness were both introduced
within the SQE in Release V5R3M0.

The DB2 SQL for i [the SQE] does utilize information from constraints for making some decisions. There had even been a defect, early-on, whereby an error in implementation effected incorrect output for having omitted rows for values which were actually in the database.

For example, the database can implicitly know that a value that is not in the parent will not be in the child, and can optimize the access plan and path for data retrieval with that understanding. That specific utilization of constraint awareness was the source of the aforementioned defect, though I do not recall the details [perhaps applying rules from a constraint that was not enforced per CHGPFCST STATE(*DISABLED) or in CHECK PENDING status]. Similarly, logic in a check constraint can eliminate selection rules, probes, and actual retrieval of data that "can not exist" according to the rules. Note that such logic makes little sense with regard to the TABLE [on which the constraints are defined] for the latter two, since the physical data is just not there [else there is a highly negative defect]; the logic applied from constraints definitely assists for improvements on [implementations effected as or similar to] join logic. If you have many values 'X' in a column used to join on a column in a child file whose parent has no value 'X', then there is no need to inquire of any INDEX on the child if there are any rows with the value 'X'; i.e. there must not be any 'X'-rows in the child, thus do not perform any actions that might otherwise lead down the path to locate any such rows.