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

Re: How to think in schemas?



This is probably a generic LDAP question - you'd be better off asking
over on umich's generic ldap list.

> What's your favorite reference for "thinking in schemas?"  I don't mean 
> just the file format, but also good to best practices for schema design, 
> accepted practices, idioms, etc.

1. Take the time to research if an applicable schema already exists, and
if so use that.  Create schema as a last resort.
2. Don't use generic attribute/objectclass names,  prepend your
organizations name or some such so that you don't overlap name-wise with
someone else's schema.  You will want to interoperate with other DSAs
someday, even if today you don't think you will.
3. Take the time to research if an applicable schema already exists, and
if so use that.  Create schema as a last resort.

> For example, in an RDB with "people" data, you might fully normalize the 
> schema so that there is one and only one record for a household's 
> address, and then associate each person that lives at that address as 
> separate records with a foreign key to the address record.  Or, 
> depending on needs, you might denormalize that design, so that each 
> person's record includes its own copy of the address data.

Totally irrelevant;  LDAP is not a relational database.  If you need a
relational model with constraints and foriegn keys, etc... use a
relational database.

> If you didn't know anything at all about RDBs, you could find many books 
> and other references that cover issues like that for RDBs.  Probably 
> none to few cover similar issues for ldap schemas.

I wouldn't expect them too.

> What do you like?

Cheese!  I like cheese.