directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: JDBC/Derby backend
Date Fri, 09 Feb 2007 00:12:18 GMT
Juergen Weber a écrit :

> I think for a JDBC backend the actual database code should be trivial
> in comparision with the database schema and mapping of LDAP queries to
> SQL queries. Probably one would end with something quite similar to
> the IBM paper 

Mapping fitlters to SQL SELECTs might be tricky, for sure...

The structure of a RDBMS schema has been kind of overviewed a few months 
ago :

But this is very initial thought...

> (is that patented in the US?)

I have no idea ... I don't know if you can patent such trivial ideas ;)

> Or a quite trivial mapping:
> and
> So ldapsearch  -b "o=sevenSeas"   "(givenName=William)"
> would map to
> select * from DNS D, ENTRIES E where D.EID = E.EID and D.EID like
> 'o=sevenSeas%'
> and E.ATTNAME = 'givenName' and E.ATTVAL = 'William'

Remember that an attribute can have more than one value. Using a schema 
where entry has three column can be seen as a waste of space, but it can 
also be a waste of time has request will need to do 2 joints instead of one.

This is where we have a lot of things to analyze, test, evaluate. Just 
consider that we might have more than one index per column. We have to 
deal with six different kind of searches :
* present : an attribute is simply present, with a non null value)
* equal : the attribute value equals the assertion value, wrt matching 
rule (that means we _must_ implement matching rules into the database. 
Not so simple...
* approx : the attribute is an approximation of the assertion value 
(soundex algorithm). How does it work for non european languages like 
cantonese or hangul ?
* greater or equal, less or equal : we need to inject the comparators 
into the database.
* substrings : equivalent to the LIKE SQL instruction
* extensible match : I don't know anybody using them, but anyway, it's 
in the spec ...

All those guys are not easy to implement and are heavily relaying to the 
Ldap Schema content. Not exactly a piece of cake to implement :)

> One would have to see how efficient this join becomes for huge 
> directories ...

Well, not necessarily worst than doint in memory joins like we do with 
our B-trees :) At least, RDBMS are very good at that, not to mention the 
optimizations you can easily do with RDBMS help (Oracle has incredible 
tools to analyze a request)

So far, the subject is damn interesting, but not as simple as we can 
think at first glance.  But I do think it worth the effort, definively.


PS : as this is pretty much Dev matter, what about switching to the dev 
ML ? (

View raw message