Without seeing your queries, I'm not sure what slows you down. Bear in mind that SQLite will use at most one index for any given query - so you should look at the generated query plan for your queries to determine if the indices you gave are actually used.
From how I interpret the documentation, SQLite will also benefit from an early reduction of the JOIN size, that is, you need to order the JOINs of tables yourself so that the initial resultset is as small as possible.
Of course, you can likely pre-cache the browsing hierarchy and optimize it for fast reads (and slow writes) by employing some triggers on the main table and the normalized browsing relationship table, and create the flattened tree with the triggers. SQLite supports triggers, but MySQL does not, so if you're planning on porting this to other systems, beware.
What problems did you find with SQLite3 that SQLite2 doesn't have ?
In reply to Re: Optimizing Tree Hierarchies with DBD::SQLite2
by Corion
in thread Optimizing Tree Hierarchies with DBD::SQLite2
by shlomif
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |