Re: OpenLDAP SQL Backend

[Predrag Balorda <pele@artewisdom.com>]

Sorry about the include but I thought it might be relevant to follow up
the whole thing...for those of you who are interested of course...

Jauder Ho wrote:
> 
>         it would be nice to have a slapd with SQL backend as a master
> server for data repository. I would love to see something like that.
> So you would have a master LDAP server with possible feeds in from other
> databases such as the HR database. and then replicate the data to a
> frontend ldap server that uses db for fastlookups and is the actual one
> clients interact with. this way data is keep current but ldap provides a
> uniform interace for directory style queries.
> 
> --Jauder
> 
> On Tue, 8 Sep 1998, Lucio de Re wrote:
> 
> > According to Predrag Balorda:
> > >
> > > Should a generic SQL interface be integrated with back-ldbm
> > > or implemented as a separate back-lsql?
> > >
> > I think the intent of the back-ldbm was to permit a broad range of DB
> > implementations, including SQL-style.  That said, I'm not sure that SQL
> > itself (I am no expert here) lends itself to being twisted into the
> > shape required by SLAPD, certainly not to the extent that Berkeley DB
> > did.  I cannot comment on the ODBC aspect, as I have yet to see an
> > implementation of anything ODBC that did not cost too much :-)
> >
> > SQL itself I have no warm feelings for, it strikes me as a nightmare
> > from the depth of line-oriented mainframe hell.
> >
> > I think the UMich approach was sensible: designing to a particular,
> > specialised objective, and I would consider efforts toward producing an
> > extremely efficient back end to be a considerably better investment.
> >
> > > Or to demistify it a bit - what about writing a PostgreSQL interface for
> > > back-ldbm. Actually I'd be happy if we could do a propper ODBC-compliant
> > > back-ldbm interface. Thoughts...
> >
> > I'm currently sitting between miniSQL and SLAPD and trying to figure
> > out which one would serve my immediate purposes better.  I'd like to
> > see a mixture of the two, somehow, possibly PostgreSQL rather than
> > mSQL, but they seem philosophically antithetical.  Not being well
> > schooled in DBs to any extent, I may however be missing some important
> > point.  I'm always ready to listen, though.
> >
> > ++L
> >
> >
Ok, well seems we have some arguments and/or misconceptions evolving
here.
Let me explain a bit.

LDAP has been designed from ground-up to use something which is
read-oriented. And unix dbm is just the thing. But, I'm not convinced
that something as simple as dbm would cope nicely with a 250000-entry
type database. I see an SQL engine as something that can be relied upon,
be it writes or reads, efficient and fast. Afterall that's is exactly
what all those PostgreSQL/mSQL/Oracle/Sybase/blah blah developers spend
their nights banging their heads about. So I think that noone knows
databases better than database people. Agree? SQL itself may be dirty or
not, depends what you like, but the whole excercise is to _hide_ the
nitty-gritty from the LDAP user. Fair enough, it might be a bit tricky
to knock out a proper database with all the referential and data
integrity that might be required for a hierarchical top-down approach to
directory-type data, and an object-oriented database would be best
(postgresql, they say is "object-relational rdbms" which encapsulates
best of both worlds I guess) suited for such purpose. But I'm not a keen
follower of such things. Anyway, afterall it might be fun (and someone
might even find some use for it - find out how much someone earns from
the pay-rolls through an LDAP server? eewww..). 
With regards to the ODBC question, well there's this FreeODBC thing that
Postgres people recommend (http://www.ids.net/~bjepson/freeODBC/) but
that's not our main concern right now...so again..thoughts people...