Hi Uwe,
Nachricht vom Donnerstag, 13. November 2003, 20:11:29:
> Hellom
> Am Thursday 13 November 2003 17:10 schrieb Spider:
>> > What should I use ? LDAP or SQL ?
>> > What would be the 4 or 5 reasons in favour of one or the other ?
>>
>> I'd say LDAP, simply because this is ldap's hometurf, user management
>> and information. However, ldap interface is clunky at times.
>>
>> SQL would be usable, but I don't think it'd be the optimal for this
>> usage area, as sql is more generic, and thus not as wellperforming.
>> Besides, LDAP is a treeview, whereas SQL is flat down, which gives
>> LDAP a better state for a thing like this.
> There are reasons why people went away from hierarchical databases.
> As soon as you have entities that might be sorted into different
> branches of the ldap tree, the problems start. Do you store these
> entities in both branches? If so, how do you make sure that it will
> be in sync? Or do you store it in only one and hope that everybody
> who needs to access it will find it? You could work areound these
> problems quite easy in a relational database.
> Best possible solution IMHO would be to use ldap as an directory access
> protocol and use a relational backend for storage. Of course you'd need
> an interface to translate the ldap queries into SQL.
man 5 slapd.conf states:
BACKENDS
The following backends can be compiled into slapd:
[some other backends]
perl This backend works by embedding a perl(1) interpreter
into slapd. The configuration file then specifies Perl
subroutines that will service LDAP requests.
shell
This backend executes external programs to implement
LDAP operations. It is is primarily intended to be
used in prototypes.
sql This backend is experimental. It services LDAP
requests from an SQL database.
You can do ldap from an sql backend, but why should one want to do
that?
Timo
--
[EMAIL PROTECTED] mailing list
