How can I index a tree in a SQLite Table? - c++

Question

I have a table with the following fields:
id VARCHAR(32) PRIMARY KEY,
parent VARCHAR(32),
name VARCHAR(32)
parent is a foreign key referencing the same table. This structure generates a tree. This tree is supposed to replicate a filesystem tree. The problem is that looking up an id from a path is slooow. Therefore I want to build an index. What is the best way of doing this?
Example Data:
id parent name
-------- ----------- ----------
1 NULL root
2 1 foo
3 1 bar
4 3 baz
5 4 aii
Would Index To:
id parent name
-------- ----------- ----------
1 NULL root
2 1 root/foo
3 1 root/bar
4 3 root/bar/baz
5 4 root/bar/baz/aii
I am currently thinking about using a temporary table and in the code manually running a series of insert from's to build the index. (The reason that I make it temporary is that if this db is accessed from a windows system, the path needs backslashes whereas from *nix it needs forward slashes). Is there an alternative to this?

Answer 1

so, you have a function that does something like this (pseudocode):
int getId(char **path) {
int id = 0;
int i;
char query[1000];
for (i = 0; path[i] != NULL; i++) {
sprintf(query, "select id from table where parent = %d and name = '%s'", id, name);
id = QuerySimple(query);
if (id < 0)
break;
}
return id;
}
looking at the query, you need a (non unique) index on columns (parent, name), but maybe you already have it.
a (temporary) table can be used like you said, note that you can change the path separator in your program, avoiding the needed of different tables for windows and unix. you also need to keep the additional table in sync with the master. if updates/deletes/inserts are rare, instead of a table, you can simply keep an in-memory cache of already looked up data, and clear the cache when an update happens (you can also do partial deletes on the cache if you want). In this case you can also read more data (e.g. given a parent read all the children) to fill up the cache faster. On the extreme, you can read the entire table in memory and work there! it depends on how many data you have, your typical access patterns (how many reads, how many writes), and the deployment environment (do you have RAM to spare?).