On 11/2/06, David Boreham <firstname.lastname@example.org> wrote: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...
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
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 any
- 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
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
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 :)