Hi Michael, > >> > If you need more performance, throw more hardware at it - > >> > a larger cache (settings -> memory), faster disks and a faster CPU. > >> > >> After adding a column for "one level up", adding indexes, optimizing the > >> query it took only a few hundreds of seconds. > > > > Of course, indices should be added to get acceptable performance. > > That's what they are here for. > > > > Nevertheless, your database design should be based on logic > > and all data should be stored normalized. If you're de-normalizing > > your design to get better performance, then there's something > > wrong with the database engine (whatever engine that may be). > > Unfortunately, there is not a perfect database engine. Sometimes you have > to break normalization to get acceptable performance, especially when you > can't through more hardware at the problem. I have no doubt that some day > every problem that must be de-normalized now for acceptable performance > can be renormalized at some future time. But you can't know when that > future time will be exactly and must accept a compromise in the meantime.
What you're saying is true. The difference is, that I will start saying: don't bother about joins causing trouble unless they do. That's different than starting to ask "do joins cause trouble". I think we agree on that. 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]
