Re: Compressed tables

>Which one can take an extra overhead, which one can
>gain from the use of a feature. What's the correct trade.

Impossible to determine up front, because it is a physical design issue, and the physical substrate changes faster than the life of the system.

Often in hindsight you see this sort of progression, assuming some reasonable development and implementation:

o Designers guess at initial data forecasts.

o Developers program to the forecasts, using currently available features.

o Implementation over time gets migrated up over hardware (the disks are full, the cpu is too slow) and software (don't want to be on 8i, eh?). So tradeoffs change. Or worse, you can't migrate.

o Requirements change, hacks are made. Where once a row was selected, now it must be run through a correction function. Where once you filled a DW, now everyone wants one heterogenous db. 10ms over 1000 users means response is too slow. You are locked into obsoleted tradeoffs.

Nothing to be pessimistic about, it just means more work for everyone!

jg

--
@home.com is bogus.
http://news.com.com/New+hopes+from+Suns+idea+factory/2100-1010_3-5896037.html?tag=nefd.lede