Re: name space design

["Karl O. Pinc" <kpinc@artic.edu>]

>hi, i'm designing an web-based registration. there will be a drop down list
>on this web-based form to select the user's department. i've thought of 2
>ways of dynamically populating the department drop-down list:
>
>1. design the ldap name space to contain department name and limit the ldap
>query to one level (from root: dc=mycompany, dc=com) to retrieve all the
>departments:
>i.e. uid=username, o=departmentname, dc=mycompany, dc=com
>
>2. store the department name in a mysql database and dynamically populate
>the drop-down list by querying mysql.
>
>my worries about method 1 is as follows:
>1. if the department changes name, how can i update the dn of all the users
>under this department tree?
>2. if a user change department, how can i update his dn to uid=username,
>o=newdept, dc=mycompany, dc=com?
>3. how can i delete a department and all the entries under it's tree?
>4. is including the o=department in the dn a good design? or should i just
>use "uid=username, dc=mycompany,dc=com"?
>5. what are the pros and cons of using "o" in the dn?
>
>using method 2, the name space design is simpler: uid=username,
>dc=mycompany, dc=com. but i have to keep duplicate/two sets of department
>records. one in mysql and one in ldap. and they must be synchronise when any
>department is modified, deleted or added.
>
>i really have no idea what might be the complications for each method and
>which is a better way of designing.
>
>would really apprecaite some insight/advice from the experienced and
>knowledgeable ldap users in this mail list.

I've no real ldap experience, but lots of database experience.  The classic
solution would be to have two hierarchies, one for the users uid=username,
ou=People, dc=mycompany, dc=com, and one for the departments
deptnumber=departmentnumber,ou=Departments, dc=mycompany, dc=com.  The
number of the department would be stored as an attribute of the person.

The only reason I can think of for not doing it this way is that ldap
dosen't seem to have an SQL like front end available so joining the users
and the departments to obtain the spelled out department name may require
some extra coding.

Note that the name I've chosen for the user portion of the hierarchy is
based on an rfc (see /usr/doc/openldap...) for the storage of unix
authentication info (/etc/passwd) in ldap.  I made up the department
portion; I was careful to adhere to the cardnal design rule of never
putting meaningful information into keys.  So, because the department name
is not in the key, it's easy to change the name of any department.

Karl

May the Legos (TM) always be swept from your path in the night.