On Thu, 30 Jan 2003, Josh Berkus wrote:
>
> The proper way to go about application design is to build your application on
> paper or in a modelling program according to the best principles of software
> design available, and *then* to discuss performance issues -- addressing them
> *first* by buying hardware, and only compromising your applcation design when
> no other alternative is available.
>
App design & performance go hand-in-hand. the trick is to balance them.
Who wants a _wonderful_ design that runs like a piece of poo? in this
case I agree with you - not the best design around. buying hardware to
fix speed problems is useful, but the software side should not be
neglected - imagine this scenario using your
methods (with a wonderful pg performance problem in hand (unless you are
running cvs))
User has a schema and writes a query along the lines of
select somevalue from sometable where othervalue not in (select badvalues
from badvaluetable where id = 12345)
we all know this runs horrifically on postgres. using your method I should
go out, spend thousands on multi-processor boxes, raid, ram
If you do a little app tuning (maybe spend 10-30 minutes readig pgsql
archives) you'll learn to rewrite it as an exists query and make it faster
than it ever could have been on the fast hardware. I just saved the
company $10k too! (depends on if you consider that change a design
change).. some designs are fatally flawed from the start. but hey.. oh
well.
'tis a fine line though.. balancing hardware vs software optimization.
(I'm also guessing they are not constrained by things such as an embedded
system too)
------------------------------------------------------------------------------
Jeff Trout <jeff@jefftrout.com> http://www.jefftrout.com/
Ronald McDonald, with the help of cheese soup,
controls America from a secret volkswagon hidden in the past
-------------------------------------------------------------------------------
