I think you may have some misconceptions of SQL. Strictly speaking, SQL
is only an access language (to use your term). A more specific term
might be a query language, or a data manipulation language. In any case,
there isn't really a need to design a new one since SQL has already been
defined and everybody and their brother knows and understands it.
Note that ODBC simply lets you pass SQL commands to the database; it
does not define a new query language.
Also, there wouldn't be a way to "slip behind SQL" ... that's the only
interface the SQL engines expose. (well, maybe there are a couple where
you can, but they) Certainly, to avoid tying yourself to a particular
engine, you wouldn't want to do this. It would also mean that you are
avoiding the benefits of SQL and simply using the engine's data storage
mechanism. Not a very efficient use of development time when the intent
is to build an LDAP system :-)
Also, I'd state that SQL is one of the best ways to work with a
relational database. The language was defined from a mathematical
standpoint based on relational theory. When you're doing some heavy
relational work, then its design begins to make a lot of sense, and
you'll be happy about it :-)
Anyhow, back to the topic: I agree that having a SQL backend would be
tremendously useful. However, it would be very hard to tie the LDAP
server into an existing SQL-based system. Generally, the LDAP server
would have its own, independent set of tables. The benefit would simply
be scaling, replication, partitioning, backup facilities, etc (rather
than integration). Of course, this also comes with a big drain on speed
:-)
ODBC would probably be a reasonable place to start, but I'm not sure how
many free SQL servers support it. I'm not sure what the SDK is like for
MySQL, but as a database, it is one of the best free DBs out there (it
does have some restrictions, though... most "free" SQL DBs seem to at
this point). Postgres is free, of course, but I had some significant
problems with that at one point -- the engine didn't support returning
the number of rows affected in a delete or update ... icky. It is also a
rather unwieldy package (endemic to SQL engines :-). mSQL was way
under-featured. I think one of the biggest problems will be finding a
free SQL engine with transactional semantics (MySQL does not have
transactions, either).
Cheers,
-g
Lucio de Re wrote:
>
> 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
--
Greg Stein (gstein@lyra.org)