[Date Prev][Date Next]
schema and tree design
I have a couple of rather "beginner-level" questions concerning the LDAP design. I don't expect you to teach me LDAP basics, but pointers to GOOD (online) literature, FAQ entries and such wold help a lot...
1) What would you use as a tree root for an international organistion? The organisation I have in mind (T-Mobile) consists of several companies that operate on local level, and at least one that is trully international. Because of the international part, using "o=T-Mobile, c=AT" (and so on ) doesn't sound right to me. The same goes for "dc=t-mobile,dc=at". At first I thought that I could go with the latter design, and use "dc=t-mobile,dc=com" for the international part, but that's used by the USA. :-(
I would be happy to go with "internal standard", even a relatively bad one, but it seems that there is no such thing yet...
2) I'm quite experienced with relational DB model, and keep thinking about "normalisation" of the data. Is "normalisation" also a thema in LDAP world, or is it OK to keep redundant data around (and why so). I ask this question, because I have found an LDAP server here that uses a schema with quite a lot of redundant info.
For instance, each user carries around some data about its place in the organisation. In relational DB, I would put a pointer from an employee to his/her superior, and thus recursively build a tree. In this particular LDAP tree, each user carries pointers to several "superiors" of different levels. For even more fun, each of these persons is redundantly mentioned in several fields (his dn, his personalID, his name).
Is this something that makes sense for LDAP (as in: "we need to do less search operations this way", "easier to browse") in LDAP world, or simply a design error?
3) I can see that OpenLDAP ships with several nice schemas (inetOrgPerson for instance), but I can also see that these schemas do not offer all the fields that I need. The question is: "what is the best way to extend a schema/make a new schema". "Best" is defined as:
* minimal work
* maximal flexibility :*)
* maximal compatibility to commercial apps that may expect some standard schema in place.
PS: I'm not sure if this kind of questions is welcome on this list, but I don't know of a better place, so...
T-Mobile Austria GmbH,
Information Technologies / Services
Knowledge Management & Process Automation
Dr. Denis Havlik, eMail: email@example.com
Rennweg 12, Zi. 444 Phone: +43-1-79-585/6237
A-1030 Vienna Fax: +43-1-795-85/6584