> >> > 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
> >> 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.
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL