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

Re: OpenLDAP SQL Backend

According to Predrag Balorda:
> 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

I'm sorry if I conveyed the impression that I disagreed on principle 
with your interests :-)

The point that I would like raised is whether one can bypass the 
cruddyness of SQL (thanks for the ODBC pointer, by the way, it may turn 
out invaluable) and actually attack the relational database principle 
from much closer to the DB engine.  To me, SQL contributes nothing to 
the capabilities of a relational database (when I first looked at SQL I 
kept thinking how much more appropriate Tcl would be for the task) and 
it is strictly my _opinion_ that relational DB engines designed to 
optimise SQL access are probably crippled.

That's of course off topic here, sorry for the bandwidth consumption.

Where I'd like to go is to define an access language (I keep thinking 
Tcl, because I'm moderately familiar with it, but Perl or Python could 
be equally good candidates) that makes the directory easier to search 
and update, and adds relational database capabilities to it, possibly 
by reaching towards the back end, or perhaps by layering the directory 
on top of the relational database in some as yet undefined manner.

All this is pie-in-the-sky, but the relational database model is 
theoretically generic enough to represent all known database models (I 
may be overstepping my understanding at this point) and it would be 
interesting to see where the intersection of directory databases and 
relational databases is.

Pure speculation, but intriguing enough to do a bit of investigating.  
My main thrust at this point is to needle Kurt into finishing porting 
OpenLDAP to autoconf, while I tweak the NetBSD configuration, then I'd 
like to look at producing a Tcl-based shell to supplement the existing 
client tools.

If Predrag is keen to look at PostgreSQL, I'll gladly help once I've 
managed to print the necessary documentation, but I would still try to 
slip behind SQL and closer to the database engine, if at all possible.  
Presumably, ODBC is more tightly coupled to the database than SQL?