[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP SQL Backend



	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
> 
>