This is what I am also saying. The effects of a bad logical DB design will effect you the most only in the long term. In the earlier stages you always trust your own design and always look for additional h/w resources to improve the performance. But in the long term you will realize that there is something other than adding h/w you have to do. That's when we actually realise the mistakes we have done in logical design phase.
suhay -----Original Message----- From: Martijn Tonies [mailto:[EMAIL PROTECTED] Sent: Thursday, September 22, 2005 3:13 PM To: mysql@lists.mysql.com Subject: Re: good database design > This is an interesting subject area. > > In a data warehousing environment, one tends to adopt table structures such > as snowflake layouts which lead to improved performance. > > Createing a perfect normalised database design may well lead to performance > issues. If this is the case, go bug the database vendors :-) ... they should give us systems that work properly ... >The more joins you have, by far the worse the performance. You may That's a pretty bold statement... > need to consider horizontal or vertical table splits. You may need to > consider replicating certain data in child tables to avoid joins. > > I am not saying you do not need to carry out data analysis and gain a > full and first hand understanding of the data structures. It is just > that when it > comes to online performance, sometimes you have to break the rules. But still: logical first, performance later... If at all. I once joined a team that had a running Oracle database and an application on top of it. We were having performance problems and there was the "2 seconds of max response time" requirement in the contract. We tweaked Oracle (not particularly the fastest beast on the block), we threw hardware at it. Both options worked... for a while. Next, we denormalized, I believe, 2 joins. Yes, it worked on fetching data - the response time was alright. But it complicated our application, the database design and the stored procedures using it... Not a particular pleasant experience. Then again... years later, I realized that the design should have been different (better logical structure) and these problems would have been avoided... Pity we couldn't do that part again... Learned a lot though. With regards, Martijn Tonies Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL Server Upscene Productions http://www.upscene.com Database development questions? Check the forum! http://www.databasedevelopmentforum.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]
