[Date Prev][Date Next]
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.
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.