Mike Jackson wrote:
Jon Roberts wrote:
Mike Jackson wrote:
Recording full DNs as attribute values is a nasty practice to
establish relationships
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.
What I wrote regarding an RDBMS was an analogy. How about this instead:
it's kind of like saying using street addresses to record where people
live is a nasty practice.
If you want
relationships, implement the logic in the client (association), or just
use an RDBMS to begin with.
... or use dn attributes appropriately in a directory. They work well
for the right cases. I try to demonstrate you can get more mileage if
you instead implement logic generally supporting DN syntax attributes
into your clients and thereby use the directory for what it does best.
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.
I'm not saying this approach is never useful because I do the same thing
sometimes, but the DN syntax can also be used to great advantage for
suitable situations. Consider this directory data generated page:
http://www.mentata.com/ds/retrieve/congress/housevote/VC107H3
Votes are recorded as DN attributes, and each member record must be read
to construct the associated link. The difference in performance between
conducting 429 searches of base one/subtree on a string attribute vs.
429 base scope searches with explicit dn is significant; I tested it.
Click on one of the members to see the reverse: an equality search on a
given value within a dn attribute.
2) RDBMS tables are not generally requested to be renamed when an
organization changes it's name; directory naming contexts are.
You're describing a particular design issue. I personally never reflect
organizational structure explicitly with the DIT. This is precisely why.
Based on what you say I can understand the design may not be within your
control, yet not every implementation will suffer that constraint.
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.
Nope, I still disagree. I would guess the lazy, inexperienced
programmers were more likely involved in the design of the directory
(please understand that isn't meant as a personal attack since you say
design was not in your purview). DN pointers as attribute values work
for me, and I know for sure I'm not the only one.
Jon Roberts
www.mentata.com
---
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.
