[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?
++L