[Fedora-infrastructure-list] Account System Updates

[Karel Zak]

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 LDAP back 
> > 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 updating but
> 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:
 cache..)

> 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
 backups, etc.

> For #2:
> - 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 writing
> external programs to do the job whether they're in an SQL or LDAP
> backend?

    Karel

-- 
 Karel Zak  <kzak at redhat.com>