On Fri, Jun 23, 2006 at 10:12:07AM -0700, Toshio Kuratomi wrote:
> Some of us are still under the opinion that it should have an
> end. Any thoughts from the new joiners?
Were the advantages discussed on the sys-admin list? Could the pros and
cons be summarised?
Every time I look at LDAP I get confused whereas SQL was easy and
intuitive to pick up. So as someone who's potentially going to be
hehe.. good point :-)
programing against it, I'd vote for staying with an SQL backend.
By the same token, I don't know much about LDAP because I've never done
anything useful with it as a backend. Is it easy to extend LDAP data?
Is it easy to program against? Can I write arbitrary queries?
About the only thing I've heard is that LDAP is:
1) lighter weight than an SQL db esp. when querying data.
2) has lots of admin tools.
In regards to 1:
- We're going to be running a lot of other tools out of SQL dbs. Does
this still make sense when we have to run an LDAP server as an addition
to our existing SQL servers?
Agree. There is not the one best tool for everyone. You have to look
for the best tool for you and for your team. I think this team is
already familiar with SQL...
- We'll be querying the data more frequently than adding or
it isn't by any means static data.
The database engine is just storage only. It's problem for middle
tier how often it will be ask for "almost static" data. (Hint:
Contributers are constantly
requesting addition to new groups, being upgraded, having their requests
denied or approved, and so forth. At what amount of data churn does
LDAP stop being more efficient than an SQL database?
LDAP is fast filesystem with btree and it's able to found an object
very fast, but I'm not sure with more complex queries (like joins
between more tables in SQL), crash recovery, redo logs, effective
- What admin tools exist that we'll be able to run? There are admin
tools available for SQL db's that we aren't currently using either....
I'm 100% that SQL has more devel/admin tools than LDAP. See around,
SQL is everywhere.
- Are the tools flexible enough to work with the extra data we're going
Please, define "extra data".
to want to associate with an account or are we going to end up
external programs to do the job whether they're in an SQL or LDAP
Karel Zak <kzak(a)redhat.com>