Re: My 10 Commandments of Database Administration...

  • From: Stephane Faroult <sfaroult@xxxxxxxxxxxx>
  • To: nsouto@xxxxxxxxxxxxxx, oracle-l@xxxxxxxxxxxxx, Niall Litchfield <niall.litchfield@xxxxxxxxx>
  • Date: Thu, 23 Sep 2004 12:01:52 +0200

I have had some time ago a private discussion on that same topic with
somebody from the list, who was pointing that 31st dec 2099 or whichever
datein the future could totally perturbate the optimizer, even with
histograms, by giving it a totally distorted view of the actual _range_ of
values. I would not absolutely condemn the fixed date in the future, though.
After all, it makes sense to mean 'for the foreseeable future', and it gives
excellent results when most of your queries only deal with current values.
Itgoes bad when you want to return both current values and values from the
recent past, because the theoretical range scan has nothing to do with the
actual one. But it is indeed far better to record known facts - dates when
things start becoming effective. IMHO it depends a lot on the amount of data
wih an historical component, and I wouldn't take the same approach for share
valuation and telecoms rates, even when everybody talks about 'valuation'.


Stephane Faroult 

RoughSea Ltd 

On Thu, 23 Sep 2004 09:52 , Niall Litchfield <niall.litchfield@xxxxxxxxx>

On Thu, 23 Sep 2004 10:40:48 +1000 (EST), Nuno Pinto do Souto
<nsouto@xxxxxxxxxxxxxx[1]> wrote:
>Quoting from AUTHOR ryan gaffuri:
>>11. Thou shalt feed me if I have to work late to fix something you
>>I'm a single guy...
>Nuno's design corollary #1:
>Thou shall not use end_date = NULL to mean "current row" of ANYTHING!
>NULL has NO MEANING whatsoever: it does NOT mean "current"!

true. But that doesn't mean you can use December 31st 2099 to mean no
end date recorded either...

Niall Litchfield
Oracle DBA[2]

--- Links ---
   1 javascript:parent.opencompose('nsouto@xxxxxxxxxxxxxx','','','')
   2 modules/

Other related posts: