The redbook DB2-400 Mastering Data Warehouse Functions sg2458184 says:

This density factor is used by the Optimizer to favor the usage of indexes that
have the highest density factor. The density factor becomes part of the
calculations for data space I/O. Since the Optimizer can take advantage of this
information, we recommend that you create EVIs (even in OLTP environment) for
keys that:
• Have keys, which are naturally clustered
For example, if the sales transactions are added daily to the file, the file is
naturally clustered by sales date.
• Have keys, which were used in a sort to load the file

Consider also that it's SOP to have EVI's over the foreign key columns
in your SALES_FACT table; one of which is usually a date key to the
DATE_DIM.

So yeah, I consider Dates to be useful for EVI's

Charles

Charles

On Thu, Mar 8, 2012 at 10:21 AM, Alan Shore <ashore@xxxxxxxx> wrote:
I have just started reading about Encoded Vector Index (or EVI)
One of the points that seems to be stressed is cardinality as far as the key is concerned.
The states of the USA is good cardinality as there are only 50 of them.
Timestamps are bad, because you can have up to a kajillion of them.
How do you determine what is good and what is bad?
For instance, a date field (or at least a numeric field which represents a date), would that be considered a bad choice for cardinality.
Cardinality - I hope I have the correct word


Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill


Disclaimer: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].