Re: [PERFORM] One large v. many small

> > 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.
> >
>
>
> fun story - I was part of a dot com and we had an informix database and
> the schema was pretty "good" - ref integrity and "logical layout". What
> happened
> was our traffic started increasng dramatically. We ended up having to
> disable all the ref integrity simply because it gave us a 50% boost. It
> was unfortuate, but you have to do it. Sometimes you have to comprimise.

You did what I was suggesting then... start with a good design and work your
way backwards for the performance you needed and not the other way around.
I've had to compromise all too often at my business (which upsets me more
because it's often cost the business more in terms of customers and revenue
in the long run, but they aren't my decisions to make), so I understand that
not everything is a matter of "do it right"... all too often it's a matter
of "get it done".

> As for throwing hardware at it - it was already running on a $500k sun
> box, an upgrade would have likely gone into the 7 digit range.

I don't envy you on that... as nice as it is to have that kind of a budget,
that adds a lot of pressure to "make it work".

> Yes it was horrid to throw out RI (which caused some minor issues
> later) but when the business is riding on it.. you make it work any way
> you can. In a perfect world I would have done it another way, but when
> the site is down (read: your business is not running, you are losing large
> amounts of money) you need to put on your fire fighter suit, not your lab
> coat.

Well said.

> anyway, sorry if I flamed anybody or if they took it personally.
> just stating some experiences I've had.

The more experiences shared, the more well rounded the conclusions of the
person reading them.

Greg