Dustin Puryear wrote: > 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. :) > > Thanks very much for your comment. Our design problem so far is still not solved but in this year it is clear we must carry out a new design, as fit as possible to reality > That said, if you find that company names are often misspelled, well, I > wouldn't use that as part of my DN obviously. Say, there are 15 people in company ABB, there are 15 entries for people, each with 'o: ABB' and there is an entry for company, also have 'o: ABB' in it. If the name is often misspelled, and it turns out this company should be ABC, then correction of name would have updated 16 entries. Lacking batch update operation in LDAP, the client application must submit ldap modify request of 16 entries.
For lack of experience, I don't know if such update (update 16 entries by client) is normally acceptable or not? Another idea is have 15 entry for 15 people, each with 'dnOfOrganization: cn=company1689,dc=xx,dc=xx' And one entry for the company, which is 'cn=company1689,dc=xx,dc=xx'. In this entry there is 'o: ABB' Using this method updating a company name is only updating one entry (not 16 entries). But, compiled search, e.g. search for all people who works in a company that contain 'chemical' in its name, would be more complex: First the client must search for all companies with 'chemical' in its name, getting a list of dn, and search for people whoes 'dnOfOrganization' is one of them. A hierarchical design solve both problems, but also have its "problem", that is rename of a company is a subtree rename operation. This is less big problem as subtree rename is widely supported. If hierarchical design isn't most suitable, I am not sure which of my two other 'solution' works better and is more commonly used/accepted? > 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. > > OpenLDAP maintain referential integrity for such case. > 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. > The difficult use case is: users are used to not to first search the company then the person who work there, rather instead they type part of company name and part of person name and press enter wishing to see the result. These user are used to do so because in the past this database doesn't have company entries, only person records, and such a person-only database can satisfy such search. As we are working on a public service with too many users we never met, it's difficult to let them change habit unless UI is very good. With the case mentioned, I don't know if a) I should update a lot of entries when a company rename or b) update only one entry when a company renames and do a lot of searches when user search for both company name and personal information or c) use a hierarchical design... -- Real Softservice Huateng Tower, Unit 1788 Jia 302 3rd area of Jinsong, Chao Yang Tel: +86 (10) 8773 0650 ext 603 Mobile: 135 9950 2413 http://www.realss.com --- 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.
