> I know the boat has probably sailed by now on this thread, but as far as I
> saw nobody has thrown in what I was going to say.
> A simple blanket statement like "Design for understanding, logic and
> maintenance, not performance." is a little too glossy.
> You can't put all database usage into the one basket like that. Some
> applications rely on a database purely as a backend, thus, a convoluted
> extremely high performance design may be favoured over a logical but
> performance one. Some applications will rely on logic and user
> to ensure that data is preserved and stored correctly, therefore a more
> logical layout will be favoured over a confusing one that may perform
> somewhat better. In the end it's up to the database designer to make the
> right decision as to what's most appropriate for the application.
> "If you need more performance, throw more hardware at it"
> You will find that in many situations throwing more hardware is _still_
> going to help. Optimizing your queries, application, tuning your server
> database design is where it's going to count most. With optimizations in
> these areas only you can cut a query that took many hours previously down
> sub second, adding more hardware in this situation is still going to leave
> you with an undesirably high execution time.
Of course, "more hardware" is after optimizing queries, indices, cache
> While I understand where you're going with your comments, I think it's
> important to make sure people know these things.
Sure is. Of course, I also had performance problems once
(with an Oracle application) and we had to resort to different
ways of doing things, by I always/still stand by my statement
that you should not design for performance, but logically
and for maintenance and understanding etc...
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL