I agree with Howard that there is no hard and fast rule here. PERSONALLY, I prefer to keep a directory flat, but odd things like facts and the types of data I'm dealing with often override that preference. :)
That said, if you find that company names are often misspelled, well, I wouldn't use that as part of my DN obviously. Also, if you have people switching from org to org often, then using the org as part of the DN is a bad idea since you'll have all kinds of updating to do after the switch. Just taking a quick glance at your problem, it seems to me that a flat structure would work better, but, as I said, I only took a glance. Maybe a few more use cases would help. -- Puryear Information Technology, LLC Baton Rouge, LA * 225-706-8414 http://www.puryear-it.com Author, "Best Practices for Managing Linux and UNIX Servers" http://www.puryear-it.com/pubs/linux-unix-best-practices Identity Management, LDAP, and Linux Integration Zhang Weiwu wrote: > Dear list > > I have been told many times that a well designed directory is as > flat as possible. Hierarchical directory often bring a lot of trouble > moving entries around. The reason for hierarchical design exist mainly > for replication and ACL control reason. While the later reason doesn't > really exist with OpenLDAP thanks to its extremely flexible ACL, the > directory server of my choice, the only remaining reason for > hierarchical design seems to be replication. > > Now I am facing a choice to choose a flat structure or a hierarchical. I > have drafted two of my choices and attached to this email. > > Every reference I read seems to suggest me use the flat structure but I > cannot solve this problem: we have two special case: > > 1) combined search for person by the company they are in is one of the > most frequent search users do, e.g. > > (sn=Wang,o=Seven Sea) -> find all Mr Wang working for Seven Sea > (l=ShangHai,o=ABB) -> find all ABB's Shang Hai contact persons > > 2) the compan name is updated very frequently, for various reasons. One > reason is spelling mistakes (the people who filles in Company Name first > time are often not native speakers of English, due to our real situation > and we administrators cannot change this.) There are other practical > reasons too. > > 3) often, each company nave many contact persons in our directory. > > With our situation it seems there is a problem we cannot solve with flat > structure: If a company name is being updated, we must locate all > contact persons in this company by doing a search, using search filter > like (o=ABB), and update every one of them. > > This problem is avoided with hierarchical structure. See the picture I > attached. If the company name change, the person node under this company > do not have to update at all. The only difference is we write filters > like this: > (sn=Wang,o:dn:=Seven Sea) > (l=ShangHai,o:dn:=ABB) > > Each time the company name is changed, we do a modrdn operation to the > company node, while do not need to update the contact persons beneath > it. > > While my practical case suggested maybe hierarchical structure is > better, I was warned a lot of times hierarchical structure rarely fits > better, especially my reason of using hierarchical structure is not the > "standard" reason given by experts (i.e. replication). So I think I > should consult experts on the list rather than head on some stupid > incorrect idea of mine. > > I can think of one downside of using hierarchical structure in my case, > that is if someone move from company A to company B, a modrdn operation > is needed rather than a simple LDAP modify operation that replace the > value of "o". I hope I didn't miss other issues. > > Thank you in advance for your time and professional suggestions! > > Best regards > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > --- > You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED] > To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as > the SUBJECT of the message. --- You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
