Jon Roberts wrote:
Mike Jackson wrote:
Recording full DNs as attribute values is a nasty practice to
establish relationships
With the current state of directory clients and supporting APIs, I
understand where this frustration can come from. However, as somebody
who tries to use DN syntax attributes to their fullest extent in my
clients, I can't endorse this statement. It's kind of like saying using
foreign keys to establish relationships in an RDBMS is a nasty practice.
DNs are an important part of how a directory works, and there is little
faster than the retrieval of a directory entry by DN or an equality
search on an indexed DN syntax attribute.
I disagree, because:
1) a directory, by design, is not a relational database. If you want
relationships, implement the logic in the client (association), or just
use an RDBMS to begin with.
An example of implementing relationships by association is when you have
multiple values for an attribute called e.g. "diskMount" in an entry,
and all objects of type "diskMount" in some other branch of the
directory. Code the logic into your client to either 1) explicitly know
the relative location under the base where objects of type diskMount are
located, or 2) just search for them.
2) RDBMS tables are not generally requested to be renamed when an
organization changes it's name; directory naming contexts are.
I have had to tackle the problem of designing tools to rename naming
contexts, and let me tell you it's not easy if the object content has
been designed by many different people as well as third-party vendors.
One would imagine that it's as simple as dumping to ldif, doing search
and replace, reloading the ldif and being done with it. With a several
hundred thousand object directory, the chances for false or missed
replacements by a script is very high, and you may not see the problem
until days/weeks later.
An example of this is an unnamed, widely deployed, third-party
application which stores 1..n DNs inside of an XML file, then loads the
file as the value of a multi-valued attribute. One entry can, of course,
contain 1..n instances of this attribute. In a usual configuration,
there are a thousand or more of these objects, in deeply nested DIT,
which could easily be missed. Do you really want to decode every base64
encoded object in a large and diverse directory, examine it, make
replacements, and reencode it? The probability of potentially unnoticed
error by a script is climbing high now...
Using full DN pointers as attribute values, or embedding naming contexts
into attribute values, is an all around bad idea, and it has nothing to
do with "the protocol" or it's data model; it was very likely the
brainchild of a lazy programmer who didn't have any practical experience
with large directories and changing political / business landscapes.
BR,
Mike
--
http://www.netauth.com - LDAP Directory Consulting
---
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.
