directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <>
Subject Re: ApacheDS partition implementation based on Relational Model
Date Thu, 02 Nov 2006 16:05:04 GMT
On 11/2/06, David Boreham <> wrote:
> Ersin Er wrote:
> > I need some advice on implementing a partition for ADS based on the
> > relational model and using SQL or Hibernate or JPA, or framework like
> > them..
> First the $64,000 question : WHY ?

If it woth 64 000$, then it's a BECAUSE :) Otherwise, there are many good
other reasons beside being greedy :
- SQL databases are reliable, when jdbm database is not
- SQL databases have a _lot_ of tools, when we don't have any - or close to
- SQL Database support transactions, and it's good to have, because we don't
support them...
- SQL Database can be replicated
- SQL Database can be stored on a SAN or a cluster easily
- There are a lot of addon like Hibernate to do the mapping on SQL database
- Some customer want trustable storage. Oraacle is trustable (well, this is
questionnable... A system is as string as its weakest element (man ?) :)
- And, so far, database are quite fast. IBM IDS is using DB2, I have seen it
running with 70 000 000 entries, and it was fast enough for our needs...

> First of all, is this realistic? Can we reach a usable result?
> Yes, but experience shows that it's typlically not worth the trouble.
> There are two common reasons for wanting such a thing:
> 1. 'Datastore envy' : 'I want all my data in Oracle' (because Larry says
> so).
> 2. Adapting existing data (hey, all our HR stuff is in an Oracle database
> underneath Peoplesoft, let's expose that using LDAP).

I never so that in real life. Generally, what I saw is people using
meta-directory or tools to export data from HR base to ldif, and import. All
that done around 3am, with manual restoration and correction at 9am, in a
fury of urgence ;) (remember, the weakest element ...)

The trouble with #1 is that once whoever it is that's asking
> is told the cost and hassle involved vs just using a perfectly
> working LDAP server that already exists, they tend to forget
> their datastore envy.

yes, but here, we are much more in a political environment. The choice of a
backend will be driven but sells, and Oracle representatives are pretty
impressive when it's come to explain companies that "oracle can do it all".
So they might chose another ldap server (well, this is a weak demonstration,
I know :). Ok, you are right, if it works smoothly with jdbm, people won't
care about having a RDBMS backend !

The trouble with #2 is that it turns into an object relational mapping
> science project. Very hard to say in advance what kinds of mapping
> are needed without seeing the use cases. So it tends to deflate into
> 'well we can write some custom hack for each individual customer'
> and 'hmm...syncing the data using a metadirectory solution is much
> easier'.

I don't really think that the RDBMS mapping will be that bad. We already
have to build a correct schema for a b-tree implementation, so it's just a
question of remapping it to relational schema. Not necesserally a big deal.

> Can we leverage the power of SQL SELECT for LDAP search operations?
> 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.

yukkk ! May be the worst solution ! The vast majority of b-trees used in
jdbm should simply be removed as they are exactly replaced by RDBMS index.
The main problem is to build the DN tree correctly, and that's it.

There have been some successful LDAP server products that
> _only_ used the relational database store technique : IBM had one
> and so did(does?) Oracle.

yes, and IBM is quite a good Ldap server, even if very heavy one :)

However, thanks for the insight, David, I pretty agree with you on some of
your points. In my mind, RDBMS backend is just a question of using
mainstream, because people want to use mainstream techno...


Emmanuel L├ęcharny

View raw message