Zhang Weiwu <[EMAIL PROTECTED]> kirjoitti:
Can I know if there is a reason to use any kind of hierarchy structure
at all? Well I already know one, ease of replication (certain subtree
can be on a different server), is there any other?
If there is no good reason or situation where we should prefer hierarchy
structure, I got a good lesson to learn this time. I was a bit "mislead"
because I read no less then 5 reference implementation (googled from
online, some are university implementation for students record etc )
before starting ours and they all use hierarchy structure. Maybe that's
because they considered this first, that a university is unlikely to
rename, but they probably also have other reasons to prefer hierarchy
structure.
There is nothing wrong with using a structure of subtrees as long as you don't
go overboard.
Subtrees are very useful for database partitioning - load-balancing purposes or
geographical data distribution.
A common use of subtree replication is to put a local repository of accounts on
a busy mail server.
dc=foo,dc=com
|
+-ou=people (subtree replicated to mail server(s))
|
+-ou=printers
On the mail server(s):
ou=people,dc=foo,dc=com
And the mailservers are configured to query localhost LDAP server...
A common use of geographical data distribution is for a multinational
organization:
dc=foo,dc=com
|
+-dc=cn
| |
| +-ou=people
|
+-dc=hk
| |
| +-ou=people
|
+-dc=tw
|
+-ou=people
Where the "dc=foo,dc=com" is little more than a container for referral objects. The
"dc=cn" branch is contained completely on a server in China, having a naming context of
"dc=cn,dc=foo,dc=com", same for HK and TW. This type of distributed database provides a global
view, with local service and data ownership and management. The country grouping of people is still probably
too broad, unless you are a tiny multinational company. If the number of employees per country are large,
then you would put for example city ou under the country objects and place each city's people in ou=people
under the city. You could in this case even distribute data ownership and service management down the
individual city branches. I build a lot of multi-national directories, so I'm pretty familiar with the ins
and outs of this..
The best practice is probably not to create branches for business units and put
people under them. Better is to use an attribute for each person:
fooComBusinessUnit, or something similar which you can use to filter against.
With this technique, you can easily make mass organizational changes without
any pain.
Feel free to contact me if you have any further questions.
BR,
Mike
http://www.netauth.com - LDAP Directory Consulting
---
You are currently subscribed to ldap@umich.edu as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
