> imagine this scenario using your
> methods (with a wonderful pg performance problem in hand (unless you are
> running cvs))
<snip>
> 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.
Your example is invalid... you're talking about an implementation detail,
not an architectural design issue.
I have to agree with the original point... normalize the database into the
proper form, then denormalize as necessary to make things perform
acceptably. In other words, do things the right way and then muck it up if
you have to.
While you make an excellent point (i.e. you can't always through hardware,
especially excessive hardware at the problem), I would err on the side of
doing things the right way. It usually ends up making the software easier to
maintain and add to. A poor design to save a few thousand dollars on
hardware now can cost many tens of thousands (or more) dollars on
programming time down the road.
I've seen entirely too many cases where people started thinking about
performance before they considered overall design. It almost always ends in
disaster (especially since hardware only gets faster over time and software
only gets more complex).
Greg