Red Hat DIRECTORY SERVER 8.1 - DEPLOYMENT Deployment Manual page 45

For example, create separate suffixes for example_a and example_b and store them in separate
databases.
Figure 4.1. Including Multiple Directory Trees in a Database
The databases could be stored on a single server or multiple servers depending on resource
constraints.
4.2.2. Creating the Directory Tree Structure
Decide whether to use a flat or a hierarchical tree structure. As a general rule, try to make the
directory tree as flat as possible. However, a certain amount of hierarchy can be important later when
information is partitioned across multiple databases, prepare replication, and set access controls.
The structure of the tree involves the following steps and considerations:
Section 4.2.2.1, "Branching the Directory"
•
Section 4.2.2.2, "Identifying Branch Points"
•
Section 4.2.2.3, "Replication Considerations"
•
Section 4.2.2.4, "Access Control Considerations"
•
4.2.2.1. Branching the Directory
Design the hierarchy to avoid problematic name changes. The flatter a namespace is, the less likely
the names are to change. The likelihood of a name changing is roughly proportional to the number
of components in the name that can potentially change. The more hierarchical the directory tree, the
more components in the names, and the more likely the names are to change.
Following are some guidelines for designing the directory tree hierarchy:
• Branch the tree to represent only the largest organizational subdivisions in the enterprise.
Any such branch points should be limited to divisions (Corporate Information Services, Customer
Support, Sales and Professional Services, and so forth). Make sure that the divisions used
Creating the Directory Tree Structure
35