Emmanuel Lecharny wrote:
>> The simplest way to do it is to construct tables that look just
like the
>> b-tree relations used in a custom LDAP data store. However this
doesn't
>> goal achieve #2 above.
>
> Can you explain this more?
Basically he's saying model the db like you do the jdbm tables in the
ldbm rip off we use for the default backing store.
Meaning you have a master table, an id2dn table, and so on just like
using jdbm tables.
If we go to RDBMS, this would be the worst approach. It is suppose to be
a relationnal model, not an hierarchical model mapped on a relationnal
model. Performance will be awfull
You're right but there is no other distinctly different approach to have
a generalized approach to storing any kind of entry in a RDBMS. Whether
you use one big table or many little two column tables you're still
going to have a mess and inefficency.
One of the reasons I wanted to stuff it all into a single table was to
avoid the join overhead. But by far the extra network latency will kill
performance way before that.
I've got to agree with David and say that any RDBMS backed backend is
not going to perform as well as a btree based implementation. This is
primarily due to the extra layer of latency you're imposing. Caching is
also an option. But at this point you might as well stop and build a
virtual directory instead. That's energy well spent.
Alex
