directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juergen Weber" <webe...@gmail.com>
Subject Re: JDBC/Derby backend
Date Thu, 08 Feb 2007 21:56:35 GMT
On 2/8/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>
> What is important with using a RDBMS as a backend is not only
> performance. You have much more than that :
> - public acceptance : Oracle, DB2, ... are almost everywhere. It would
> be bad to ignore this fact
> - fault tolerance/reliability : do I have to add anything?
> - transaction support. RDBMS support it natively
> - Knowlegde : so many DBA, so few JDBM programmers...
> etc...

- Database backup and recovery

Yes, I think too, that this points are more important than performance alone.


> > But in this same FAQ entry Kurt Zeilenga gives a link to an IBM paper
> > describing their database backend which quotes good performance (which
> > matches our user experience with the z/OS LDAP server).
> > http://www.research.ibm.com/journal/sj/392/shi.html
>
> They are both interesting papers, but both a little bit outdated.
> Anyway, the rational for using something different than a RDBMS is
> pretty clear.

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 (is that patented in the US?)

Or a quite trivial mapping:

DNS: DN | EID

and

ENTRIES: EID | ATTNAME | ATTVAL


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'

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


Juergen

Mime
View raw message