RE: Using 12/31/9999 in a date field

From: Mark W. Farnham <>
Date: Fri, 20 Dec 2013 18:46:40 -0500
Message-ID: <05d701cefddd$bc4373e0$34ca5ba0$>


where (<context date> is <= nvl(end_date,to_date('99991231','YYYYMMDD') and <context date> >= start_date)

does not involve an OR and seems pretty clear to me.


-----Original Message-----
From: [] On Behalf Of Sent: Friday, December 20, 2013 2:42 PM
Subject: RE: Using 12/31/9999 in a date field

I got the use case. Basically, the developer says that developers don't know how to code for null values and that's why this is preferable.

"The answer fails to recognize the realities of real-world usage.

In a scenario in which Point-In-Time ("PIT") queries are common, and the database is being used as a read-mostly repository of client master records, all of the queries will expect a context of "for what date do you want to see the record of the client's info?". This means that the WHERE clause will always contain

Where <context date> is between Effective_Date and Expiration_Date

If the Expiration_Date is Null instead of containing an "infinite date" like 12-31-9999, the query needs to have

Where (<context date> is between Effective_Date and Expiration_Date) Or (<context date> >= Effective_Date and Expiration_Date is null)

Which is unintuitive and has a high rate of developer errors across all of the applications/tools that write queries against the data.

Also, since b-tree indexes do not index Nulls, an index combine cannot be used to satisfy the queries."

I'm thinking an NVL function in a function based index would allow decent performance for the latter query but I'm not sure if this is worth fighting over since the column will only be accessed for reporting purposes.

Jay Miller
Sr. Oracle Database Administrator

-----Original Message-----
From: [] On Behalf Of Jonathan Lewis
Sent: Thursday, December 19, 2013 2:58 AM To:
Subject: Re: Using 12/31/9999 in a date field

That's a very good point, of course.

There are a number of side effects that could follow from (a) indexing on just a date-only column, and (b) indexing a column where a single value can have a large number of rows (especially with a constant stream of new rows appearing and old rows disappearing). You may be heading for the worst possible combination - though how much that matters does depend to a very large extent on the actual pattern of use of the column.


Jonathan Lewis m/all-postings&k=%2FJMyfAnQZOhZ4dnr8BYv6w%3D%3D%0A&r=DUCASJ0xPpeOmtQ4idyytbA D3iZK7MOOurZhynw7YaA%3D%0A&m=NrNs4jma5vdpv2gORcG72CIsvHQaPpYTaKAkSjBn7PE%3D% 0A&s=17cbd7411182cdf3f0efbc53ab3aa0e01acf67d5a15b896fed397d63e42875fc

Author: Oracle Core (Apress 2011) 43&k=%2FJMyfAnQZOhZ4dnr8BYv6w%3D%3D%0A&r=DUCASJ0xPpeOmtQ4idyytbAD3iZK7MOOurZ hynw7YaA%3D%0A&m=NrNs4jma5vdpv2gORcG72CIsvHQaPpYTaKAkSjBn7PE%3D%0A&s=10b7312 3c1fedb0b71610aea45bd1aec304ee4c8447005d3f51acadd1506c31d

  • Original Message ----- From: "Michael Haddon" <> To: <> Sent: Thursday, December 19, 2013 12:54 AM Subject: Re: Using 12/31/9999 in a date field

| This is a perfect case of a lopsided index if the column is indexed. It
| would result in a huge number of gaps in the leaf blocks as the records
| were updated to a valid date value. I would never recommend this.



Received on Sat Dec 21 2013 - 00:46:40 CET

Original text of this message