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. Kind Regards, Lachlan Mulcahy -----Original Message----- From: Martijn Tonies [mailto:[EMAIL PROTECTED] Sent: Friday, 9 July 2004 10:28 PM To: Margaret MacDonald; [EMAIL PROTECTED] 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. With regards, Martijn Tonies Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL Server. Upscene Productions http://www.upscene.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
