[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: DIT tree question

I don't know that I qualify as a heavyweight, but my first impression is that your trying to use LDAP as a database rather than as a directory server. Also, your 4 component DNs violate the LDAPv3 spec -- I don't know whether OpenLDAP will support that or not. The left most component should be an absolutely unique RDN (which uid typically qualifies as). The remainder is the suffix. You should, therefore, swap the 1st and 2nd components.

If I were creating a relational database, I would set up a table of elements that applied to everybody, and then tables for the org unit specific elements, etc -- you let the data define the table structure, normalize everything, and then use joins, etc, to present the data in a human intelligible way. That's a normative thing one does with regular databases.

However, though LDAP can be used that way (sort of), it's like using a pocket knife in lieu of a screwdriver -- it's simply the wrong tool. Other than by using separate LDAP servers, LDAP does not have an equivalent of tables. Everything is just one big data-store. You would, therefore, either have to completely replicate the data for each uid/ou combination, or write the front-end search tools to do multiple searches and then merge the data. This means that the search tool must be aware of structural components (which is a bad idea), and that applications that already are LDAP aware won't be able to take advantage of that awareness.

I manage servers at Linfield College. We have faculty, staff, administrators, students, and departments, all of which are defined as ou's. Each entry has some subset of that group (and also ou=People). I also created a special linfieldPerson object class that has all our specific attributes. Amongst those attributes, for example, are "major" which applies only to students, and "discipline" that applies only to faculty. If the attribute applies, it is populated with data, otherwise it simply doesn't exist. If a database table defines an column, it defined that column for every row, and intermixing students and faculty in the same table, and including a columns both for discipline and major, violates (I think) first normal form. That does not apply to LDAP because LDAP is not a database specification. If I simply dump a faculty entry, I won't even see and empty major attribute in the list. And, by the same token, if I simply dump a student entry, I won't see an empty discipline attribute. The intelligence to know about either major or discipline as attributes is in the application that uses that particular data -- which is where it belongs.

Basically, the bottom line is that all the attributes specific to each ou all belong together in the entry for the person to which they apply. Think of it like a phone book (the primary example of a directory). If I want to lookup John Smith, do I simply lookup John Smith and find all the information right there? Or do I have to know in advance every department John Smith might work in, and lookup him up in two or three or four different locations?

Hope that helps.

-- Rob

--On Monday, February 05, 2001 02:12:41 PM +0100 Torgeir Veimo <torgeir.veimo@ecomda.com> wrote:

Could the LDAP heavyweight share some light on a DIT tree design issue
we have?

We have user that _might_ be in several ou's, usually they aren't. Our
problem is that these different ou's want to store different
attributes that are specific for their ou. Some of these attribute
names might be the same accross different ou's, but the values will
be different.

Thus, we can either use dn's such as

uid=alan, ou=ABC, dc=ecomda, dc=de    for ou ABC
uid=alan, ou=XYZ, dc=ecomda, dc=de    for ou XYZ etc.
uid=alan, ou=VBG, dc=ecomda, dc=de

This would allow us to store different attributes for this user for
each ou, but it would be an administrative problem since we must
synchronize the data that is really common, including password etc.

We could also use dn's such as

uid=alan, dc=ecomda, dc=de                     for the common
attributes

ou=ABC, uid=alan, dc=ecomda, dc=de     for the attributes specific to
ou=ABC
ou=XYZ, uid=alan, dc=ecomda, dc=de     for the attributes specific to
ou=XYZ, etc.
ou=VBG, uid=alan, dc=ecomda, dc=de

This would be nice since we wouldn't duplicate attributes, and we
could use different object classes to store different ou data.

The problem with the latter design is that it might be harder to
subdivide the tree to different servers based on subtrees for each ou,
or to make attributes visible based on ou.

The ideal sollution would be to have both ways of accessing the data,
ie. use the second approach, but also be able to have the first dn's
as an LDAP "view".

I've also heard about auxilary objects which would solve our need if
they cold be labeled with the ou's name, but I don't have more
information at hand about these.

I'm quite new to LDAP so please bear with me if I have overlooked
anything.


--
- Torgeir






      _ _ _ _           _    _ _ _ _ _
     /\_\_\_\_\        /\_\ /\_\_\_\_\_\
    /\/_/_/_/_/       /\/_/ \/_/_/_/_/_/  QUIDQUID LATINE DICTUM SIT,
   /\/_/__\/_/ __    /\/_/    /\/_/          PROFUNDUM VIDITUR
  /\/_/_/_/_/ /\_\  /\/_/    /\/_/
 /\/_/ \/_/  /\/_/_/\/_/    /\/_/         (Whatever is said in Latin
 \/_/  \/_/  \/_/_/_/_/     \/_/              appears profound)

 Rob Tanner
 McMinnville, Oregon
 rtanner@cheshire.onlinemac.com