RE: Monolithic vs fragmented indices

> > > 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? A GK index is an index built off of the result of a query (essentially). Hence if the contents of your query change - yes the index needs rebuilding. It can be of limited functionality because of that - but it sounds like the beastie you were looking for. I believe that all other index types retain their dynamic nature. Of course I operate without indices at all, so I'm no expert (on that and a lot of things). > > 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. Not sure I follow. > > 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. I'll have whatever he's drinking. (knee-jerk reaction) Perhaps that's not an unreasonable concept. (after a moment). So you are placing a constraint on a table that points to two (or more) different tables based on the contents of the column(s)? Interesting. I suppose you could do something like that now with an SPL (depending on your front-end) or trigger/SPL combo. That might be an easier thing to do. I know that the last thing Informix wants to do is handle all of the one-offs. If you can come up with support for this sort of thing from more than just one person - your feature request might even get paid attention to. > > 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... > cheers j.