We have about 44,000 records in our database for faculty, staff and
students. Right now we use a "handle" to uniquely identify each record. The
handle has no hierarchical value - it doesn't relate to any geographical or
organizational location. In the case of students, there really isn't much
information in the database to categorize the records, beyond the fact that
they are students. Faculty and staff are also difficult to define based on
any consistent hierarchical attribute because the contents of the
"Department" field vary depending on who happened to fill out the paperwork
for that individual on that person's date of hire or transfer.
Here's how I see my options for getting my existing data into X.500
DN-style format:
1) I can toss all the existing data and start over with X.500-style naming.
2) I can take whatever happens to be in the "Department" field and cat that
together with the name, organization and country to create a DN.
3) I can kludge things by making the DN a cat of country, organization,
handle and CN.
Option 1 is unacceptable in terms of workload, politics, and all-around
feasibility. I would have to determine a sufficiently detailed level of
hierarchy to ensure that each of the 50 Tran Nguyen's (and multiple James
Lee's, Larry Johnson's, and until last month, Kenneth R. Weiss's) records
resulted in a unique DN. I would have to establish standard department and
subunit (and probably sub-sub- and sub-sub-sub-unit) names and ensure that
they were used properly by the many hundreds of people on our campus with
update privileges to the personnel and student databases. And, we would
either have to continue to use our handles for the many large systems that
already depend on them as unique foreign keys for retrieving data from the
demographic databases, or we would have to rewrite all those large systems
to use the X.500 DNs. Or, I would have to get about 500 people on campus to
put up their own slapd servers and maintain their own directory
information. None of this is likely to happen in my lifetime.
Option 2 would be easy enough to implement. However, I have over 450 people
with the last name of Lee. I have over 500 records with a last name of
Nguyen. I have over 50 records with a CN of Tran Nguyen, and almost all of
them are students. That means that I'll end up building a large number of
DNs that are not unique. I don't know if this is a problem or not.
Obviously, searching for Tran Nguyen will return 50 hits no matter how
fully you specify the search. That's a problem, but so is asking 411 for
the phone number of John Lee in San Francisco. You don't get a usable
result, but you don't break the system, either. Will duplicate DNs break an
LDAP system, or will they just return multiple hits?
Option 3 would also be easy to implement and it would assure unique DNs,
but it seems rather antithetical to the whole concept of X.500-style
naming. It's also very cumbersome, since most people here at Davis don't
even know what their own handle is, let alone people from outside searching
our database. I'm not sure how useful the resulting database would be. It
would also make it difficult or impossible to join our database with a more
global server, since our DNs would not follow a standard hierarchy for
query resolution.
Has anyone else been through this problem before, and found a reasonable
and successful solution? Am I just missing something simple and obvious
that will make the whole mess disappear?
--Ken
---------------------------------------------------------------------------
Ken Weiss krweiss@ucdavis.edu
Distributed Computing Analysis & Support 916/752-5554 (voice)
2323 Academic Surge 916/752-9616 (fax)
U.C. Davis
Davis, CA 95616 http://dcas.ucdavis.edu/kenhome.html