Re: Monolithic vs fragmented indices

Parker, Jack wrote in message <95pk7u$rpq$1@news.xmission.com>... > >Finally getting to this thread, been too busy dreaming up spicy comments. > That thread is getting decidedly chilli >I'd like to point out that what Andrew wants is the GK index which is an XPS >feature. Yes you have to rebuild the index occasionally, keys don't just >age off of it, but you can build the index on a subset of your data. Of >course index builds take no time at all. > Being almost but not quite completely ignorant of XPS... that sounds interesting. From a 15 minute glance thru a brochure, it sounded like many of the XPS special indexes require total rebuild as soon as you modify data - which is considered reasonable in warehousing, but a bit of a bougher in OLTP. Will they ever arrive in IDS and co, and will they be dynamic? It seems entirely possible that the existing fragmentation and "check contraint" teshnolojie could support implementation of dynamic indexes without excessive trouble, but of course there'd be a shoe-load of work to do to the optimiser - add another N! possible query paths... hmm - the XPS optimiser must already consider them, so I guess Informix understand the science. Related to my imaginary (no, REAL indexes!) would be the possibility of partial FK's. Some design methods yield columns that should FK(a,b,c) to one table under condition A, and FK(a,b,c) to a different table under condition B and so on. Perhaps that sort of thing should be designed out with intermediate tables? After all, I did read about it first in an Oracle design book that I grabbed in a bookshop several years ago! Chortle...

In the year of Our Lord Wed, 7 Feb 2001 10:18:07 +1100, "Andrew Hamm" <ahamm@sanderson.net.au> spake, saying: >Parker, Jack wrote in message <95pk7u$rpq$1@news.xmission.com>... >> >>Finally getting to this thread, been too busy dreaming up spicy comments. >> >That thread is getting decidedly chilli And not worth a hill of beans. .