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 but
extremely high performance design may be favoured over a logical but average
performance one. Some applications will rely on logic and user understanding
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_ not
going to help. Optimizing your queries, application, tuning your server and
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 to
sub second, adding more hardware in this situation is still going to leave
you with an undesirably high execution time.
While I understand where you're going with your comments, I think it's
important to make sure people know these things.
From: Martijn Tonies [mailto:m.tonies@stripped]
Sent: Friday, 9 July 2004 10:28 PM
To: Margaret MacDonald; mysql@stripped
Subject: Re: Cost of joins?
Design for understanding, logic and maintenance, not performance.
If you need more performance, throw more hardware at it -
a larger cache (settings -> memory), faster disks and a faster CPU.
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=1