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

Re: schema and tree design

On 18 Mar 2004 at 14:03, denis.havlik@t-mobile.at wrote:
> 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...

The closest thing to a de-facto international standard would be to use your 
unique DNS name, so dc=t-mobile,dc=at is where you probably want to be.  
Although some characters need to be escaped before OpenLDAP can deal with them 
in its database loading routines, I'm 99% sure that "-" is not one of them.

> 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?

LDAP servers are optimised for read speed and not DB space utilisation or write 
efficiency.  In addition, LDAP servers need to be able to present differing 
views of data for different access levels and applications.  There is little or 
no benefit to be gained from normalisation.  That being said, I'm sure you can 
do it if you really want to.

> 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.

Get your own OID if you need new schema items.  You'll regret it if you don't!  
See the OpenLDAP FAQ for more information; if you are not going to use OpenLDAP 
you'll be better off consulting the docs of whatever server you plan to use.

> thx
>         Denis
> 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...

Not really.  This is OpenLDAP-software, which is not intended for the 
discussion of general LDAP principles.  I think the University of Michigan has 
a list for that.

> T-Mobile Austria GmbH,
> Information Technologies / Services
> Knowledge Management & Process Automation
> Dr. Denis Havlik,                             eMail: 
> denis.havlik@t-mobile.at
> Rennweg 12, Zi. 444                       Phone: +43-1-79-585/6237  
> A-1030 Vienna                                  Fax: +43-1-795-85/6584