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

Re: Need DOCS

I think that you need to back up and think some more about the nature of
objects in an X.500 directory (which is the model behind the data stores
to which LDAP gives access).

Whenever you find yourself thinking that an LDAP-accessible service might
be a good replacement for some random database, think again.  In
particular, the relational model seems to me to be much more general than
the hierarchial X.500 model, and you may find there are relationships that
just don't fit very well into a directory.

A typical solution to the "clubs" problem would not make either kind of
object (person or club) subordinate to the other.  A club could be a
subclass of, say, groupOfNames, with its members enumerated in the
multiple-valued "member" attribute.  Or you could find an attribute of the
object type representing a person, or create a subclass and define such an
attribute, to hold the list of clubs of which a person is a member.  You
might even crosslink the two objects by requiring matching member and
member-of attribute values on instances of both object types (with the
interesting integrity issues that arise in this case).

Containment is much too strong a condition to represent club membership.
A person might be a member of multiple clubs, and a club with only one
member would be pointless.  Persons and clubs should be peer object types,
and the relationships among them should be expressed in the attributes of
instances of the types.

You might want to have a look at the IBM Redbook _Understanding LDAP_
(SG24-4986-00).  You can read it for free at IBM's site
(www.redbooks.ibm.com), or buy paper copy for quite a modest price as
compared to other tech pubs.  It's a good introduction to concepts and
practice.

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
MS Windows *is* user-friendly, but only for certain values of "user".