On Nov 2, 2007, at 11:15 AM, Steve Linberg wrote:
The other possibility I was considering was to have a new object type for a "location role", with a location code, a role code, and an employee ID to map back to the person record, but the fact that each of these would have to have a unique DN seemed redundant and wasteful - really, the DN could itself contain all of the data, since it would basically be a primary key, so you'd have a structureless object like "employeeID=12345,cn=location_a,cn=role_d,cn=people,dc=foo,dc=org" without any actual content? That didn't make much sense to me when I was thinking of it, but I know I still have SQL and relational tables on the brain with this method, and this approach doesn't seem to make much sense from what I understand about LDAP. If there's a way to do it this way, though, I'm also open to considering it - in some ways, it would be easier because less application-level parsing would be required to retrieve the information, and queries could play a bigger role...
Structurally, the right way to do the above in LDAP would be to have these objects be children of the employee object, and probably pick the location or role as the additional left-hand element of the DN. If you used location for that, then role would be an attribute within the object. I don't know if AD allows a person object to have children or not.
-- Michael A. Grady Senior Technology Architect and Strategist Office of the CIO -- CITES University of Illinois at Urbana-Champaign 2222 DCL, MC 256, 1304 W. Springfield Ave., Urbana, IL 61801 217.244.1253 phone, 217.244.4780 fax --- 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.
