Comments on: Death of the End Date – How LAG and LEAD help fight redundancy

By: Garri

Garri — Fri, 20 Jan 2006 14:54:56 +0000

hi
Why do not answer my question?

By: Sreenivasarao

Sreenivasarao — Fri, 02 Dec 2005 08:11:52 +0000

I want to know the date format in Oracle Warehouse Builder.
I wanted to filter the data based on a column Date.
The date format of this field is ‘MM/DD/YYYY HH24:MI:SS’.
I want to filetr the data based on a single day.
I am giving the filter condition in Filter transformation is
TO_DATE(INOUTGRP1.DATE,’DD-MON-YYYY’)=TO_DATE(’13-12-2004′,’DD-MON-YYYY’)
But it is not working.If u know the solution of this problem, please let me know.

By: Toon Koppelaars

Toon Koppelaars — Mon, 03 Oct 2005 21:27:12 +0000

Just a quick response on the overhead of the analytical functions…

Granted, the plans with the analytic functions are (still) most likely to be more expensive (both

cpu+I/O) than the redundant datamodel scenario: this mainly depends on the clustering factor for the

primary key index.

The execution plans DO NOT scare me however, AND are MUCH better than the queries we had to write in

the days when we did not have available to us the analytical functions (nested subqueries to find

maximum begindate before sysdate, etc.).

By ‘do not scare me’ I mean that I’m more than happy to trade-off the overhead for these queries

against the code that I’d have to write to implement the ‘redundant enddate’ business rule including

the runtime overhead it generates in transactions (as described by Lucas above). I have yet to

encounter the first production database (that is running for a few years) that has redundancy in

it’s datamodel, AND has no violations with regards to this redundancy…

I very often have discussions with ‘designers’ that create datamodels with redundancy designed into

the model: ‘For performance reasons’… With the current state of the optimizer technology available

to us, I always first disagree with these design decisions. I always seek proof that the queries

that this designed-redundancy is targetting, will come out as the bottle-necks of the system to be

built. To no suprise such proof can rarely be given… And then I veto the redundancy.

By: Jeff Moss

Jeff Moss — Fri, 30 Sep 2005 08:25:37 +0000

What you say is perfectly correct, however, I would have to be a little concerned with the efficiency of needing to use
the analytic function every time I wanted to work out for my given point in time all those records which were applicable.
I’ve not tested it but I’m guessing the analytic approach would be slower – and in a warehouse situation (which is what
I’m normally in) then the number of rows on the table you are scanning can be significantly large which might make the
performance differential significant enough to warrant not doing it that way.

We also use the END_DATE of NULL for partitioning purposes – to segregate current open rows from historical closed rows so
that’s another use for the physical END_DATE column.

Also, it does make the assumption that the record can’t go away and then come back – which for some of our tables is not
the case. Maybe the government come along and want to make a public footpath between the two gardens – now you have a gap.

Nice article.