[Date Prev][Date Next]
Re: LDAP programming book
- To: "Murray S. Kucherawy" <email@example.com>
- Subject: Re: LDAP programming book
- From: Edward Capriolo <firstname.lastname@example.org>
- Date: Mon, 28 Dec 2009 11:37:26 -0500
- Cc: "email@example.com" <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8vklrmmVdwsk0fRfLBgMHqIYLfqGqgfPtPFN56pP+Eg=; b=qC0I8HG+A2Bvyb4kue7mRe6goRvtM8OfD7HlxucPej150cxNXNTD4C80VV7FayXyey KVIkBTqnGeO+w0AvPymaWg3HkRWphRkMcWVEwKLlECWQsKq1JJUdOgxWOHvHQGU201eR VPidjWObAH+ppmCN8lp7zxfiNQxHM37YhGxvE=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dUKcgkEfP3zq0lbUeJiwYXxCXgIReNinOJMTtvNJsAQZ+8LBSUSgD/XUPwkzjzNQ2A xjpKaK50wVDMo8/VIffVouJ2cYl1V0egLGJAMGxLvGyqXlH2q91F772ZArocvfmud1ZT yUjGdczIIOSHfcDaQkXTXur4xMPL4ocCevg/E=
- In-reply-to: <BB012BD379D7B046ABE1472D8093C61C01C1E8A279@EXCH-C2.corp.cloudmark.com>
- References: <BB012BD379D7B046ABE1472D8093C61C01C1E8A279@EXCH-C2.corp.cloudmark.com>
Even though LDAP schema is very extensible, it never took off as an
extensible data store. You can find many books showing how to model an
object into 3nf for example, but few that demonstrate this with LDAP.
I worked at a company that used LDAP as a backend data store for
users, publishers, and subscriptions. Many times we talked about
moving the data to a relational database mainly because third normal
form is very established and LDAP design patters are lacking.
For example, several times I would get a request from a developer to
add different elements to the schema. Then I would ask back "How
should I index this data?" then would say "Turn on all the indexes",
this is usually a bad idea, and it showed that they did not understand
the implications of schema and indexing at a very high level.
LDAP as a custom data store turns out to be a very interesting way to
store data. We had a very fast, fairly large directory. Being able to
have a hierarchical layout rather then join tables was very effective
for our application.
IMHO. the problem is that most documents on the subject use LDAP only
as a user directory, and do not do much to suggest other ways to use
On Sun, Dec 27, 2009 at 6:08 PM, Murray S. Kucherawy <email@example.com> wrote:
> Is the 1997 book “LDAP: Programming Directory-Enabled Applications” by Smith
> & Howes reasonably current to the latest OpenLDAP releases, or has enough
> changed in the intervening 12 years that it’s not worth getting?