[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP SQL Backend
> Greg Stein <gstein@lyra.org> writes:
>
> > ODBC would probably be a reasonable place to start, but I'm not sure
> > how many free SQL servers support it.
>
> Worse, ODBC is basically flawed: it needs to be supported by the RDBMS
> in question on each platform you want to access it from. ODBC moves
> the system dependent interface out to the client, instead of being a
> standard network interface on the system running the DBMS. I couldn't
> believe my eyes when I first read this...
>
> > 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).
>
> Among other things, MySQL is not a multi-user RDBMS. Lacking support
> for transactions, it cannot be safe in a multi-writer environment.
>
> > 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.
>
> I think you'd do well to look at it again. Much is happening, and has
> been happening with PostgreSQL, and the current versions (6.3.2 is
> current, 6.4 is going into a feature freeze for beta testing within a
> few days time) are very, very good. There are also interfaces from
> all sorts of things: ODBC driver for windows, libraries for C, C++,
> Perl, Python and others, PL/TCL (that is, TCL with SQL extensions as a
> stored procedure programming language) already present, and a PL/SQL
> on the way. Also among new features is the inclusion of 'ecpg', an
> embedded SQL preprocessor for C.
>
> -tih
I think it would be nice if some interpreted language like Perl, PHP,
PL/TCL or something, were used as a backend. I'm not quite sure how to
do this. The benefit from this is that these languages have support for
a lot of databases and the code can easily be customized without changing
the openLDAP binary. What SQL queries to perform to satisfy the different
LDAP requests will vary from site to site I think. I don't think one can
make a fixed set of queries that suits all.
Stig
--
Stig Venås Tlf: 73 59 53 29
Norges teknisk- Faks: 73 59 80 98
naturvitenskapelige universitet
ITEA/Nett, Prof. Brochs g. 6 Epost: venaas@itea.ntnu.no
7034 Trondheim