Re: Compressed tables

"Joel Garry" <joel-garry_at_home.com> wrote in message news:1129574858.085327.22520_at_g14g2000cwa.googlegroups.com...
> >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.
>

    I sympathise, but don't entirely agree. Unless the purpose     of the system changes dramatically, the critical requirements     for performance will usually dictate the most apropriate     feature set.

    If the documentation exists that lists why feature X was     chosen over feature Y, then a change to the system     requirements that makes feature X a liability (which is the     only change we are worred about) will be obvious, and     the cost/risk/benefit analysis FOR THE CHANGE will     show whether or not the change should be implemented     by moving from feature X to feature Y or, perhaps more     realistically, how long you can run with feature X before     you are up the proverbial creek.

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

    Alas, this leads to a circular argument: reasonable development     and implementation means all sorts of good practice that pre-empt     the worst excesses:
>
> 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.

    In a good working environment, this is where the biggest threat     lies. But the word 'hack' identifies the real issue. Requirements     do change and the system is supposed to be a completely different     system. (Small changes in purpose are unlikely to make a design     strategy change from being appropriate to being a disaster).

    But if no-one notices it's a new system (which is clearly identifiable     because the original definition of the system said: "This system does A,     and the implementation works because we used feature B to make it work")     then the "reasonable development and implementation idea" has broken     down.

    It is possible at that point to say: "we have the option to change     features, do things differently" It's just another cost/risk/benefit analysis.

    Unfortunately, it's too easy to just keep going, without anyone realising

    that a particular change is dramatically opposed to the original physical

    design intention.

>
> 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
>

-- 
Regards

Jonathan Lewis

http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html
Cost Based Oracle: Fundamentals
Now available to pre-order.

http://www.jlcomp.demon.co.uk/faq/ind_faq.html
The Co-operative Oracle Users' FAQ

http://www.jlcomp.demon.co.uk/appearances.html
Public Appearances - schedule updated 4th Sept 2005