[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: LDAP vs. Relational
Hi all,
this is very interesting, indeed. And I think I have an extra question to
raise here, as it relates to this thread.
LDAP is optimized for read access as write operations are less frequent. But
does it provide any lock mechanism for concurrent write access? That is a
very delicate point. Even if we can live without transactions, we must
guarantee that concurrent write operations don't mess data. If two
operations have to update an entry at the same time, what happens?
Maybe LDAP simply relies on the fact the directory data must be carefully
designed, so there will always be exactly one data owner for each attribute
in the schema. If that is the case, the risk if very high, in my opinion.
Luca
-----Original Message-----
From: Mark Wilcox [mailto:mark@mjwilcox.com]
Sent: Thursday, May 06, 1999 8:21 AM
To: Tod Thomas; openldap-general@OpenLDAP.org
Subject: Re: LDAP vs. Relational
Hi,
Well you are partially right.
LDAP is a protocol. What LDAP really provides is this:
a common means of access to objects over the network via an open standard
protocol.
Where LDAP really pays off is when you have information that is read more
often than written to (though the write performance is improving).
An API just makes it easier on the developer to communicate with a directory
server via LDAP (much in the same way a telephone makes it easier to
communicate with your mom via your native language).
In the LDAP gateways that I have tested against they work ok if you need to
get access to an existing database of email addresses or a small set of
userids for authentication. They just don't peform very well when put under
a serious load, nor do they usually fully support the full LDAP v3
specification. This is because things like RDBMS are optimized for
transactions and complex relational queries while LDAP is designed for very
fast lookup of information.
That being said, a RDBMS is usually a good solution for a "registery". A
registery is a database where you first combine your data and then publish
into your LDAP server for interfacing. RDBMS work well here because they
usually have better write perfomance, but better they have transaction
control, something LDAP doesn't have (yet ;).
(Thanks to Jeff Hodges at Standford for the registeries concept).
Here's a good info on the importance of a registery in the implementation of
LDAP
http://www.stanford.edu/group/itss-ccs/project/registry/
If you are thinking of using LDAP to build your infrastructure (e.g. single
logon, certificate management, etc), it's better to go with a "pure"LDAP
server. They will be optimized for LDAP performance (just as a Web server is
optimized for HTTP performance and HTTP gateways on other systems are not).
This is just like using a real saw to cut a piece of timber because that's
what it's made for. A LDAP gateway on an existing database too often is like
using that little puny saw you find on a Swiss Army knife. It cuts a few
things, but you wouldn't want to build a house with it. ;)
Hope that helps.
Mark
-----Original Message-----
From: Tod Thomas <tthomas@chubb.com>
To: openldap-general@OpenLDAP.org <openldap-general@OpenLDAP.org>
Date: Monday, May 03, 1999 7:12 AM
Subject: LDAP vs. Relational
>First, let me apologize if this question sounds a bit naive or has been
>asked before. It came up in a meeting I attended a few days ago and I
>think it is relevant. I have to admit I don't have a complete answer
>and thought it would be best to present it to a larger community to get
>a broader perspective.
>
>I've been involved in directory services using LDAP off and on for about
>a year now. My approach has been that LDAP provides a centralized
>resource of relatively static information that can be easily accessed by
>a standard set of API calls. With that in mind I have implemented a
>directory that has H/R information that can be shared over our Intranet
>and accessed using a standard web browser.
>
>However a larger number of software manufacturers, relational database
>in particular, are marketing themselves as LDAP compliant. The LDAP
>API's can be used against a relational database and data will be
>returned as if it was a directory. I've done this against a Lotes
>Domino database and although limited, it works satisfactorily.
>
>The question is this: If I can get information that I could store in
>the directory from an LDAP compliant database using the API calls what
>would be the point of installing and supporting a directory ? Would it
>not then be reduced to a programming exercise of pointing your
>application to the named database that has a version of slapd running?
>
>Please enlighten me. I think my efforts and my time invested thus far
>have been worthy but I need to provide better justification if I want to
>expand the scope of my work so far. Thanks in advance for any help or
>opinions.
>
>Tod Thomas
>
>