LDAP SCHEMA DESIGN(三)

3.2 Do not modify the standard schema definitions（不要修改标准schema定义）
The set of attributes and object classes described in the LDAP RFCs sometimes appear to be rather awkward. This is not surprising, as they were derived from many different postal and telecomms standards, and new ones were created whenever the early directory service developers found a new requirement. As a result, people are often tempted to “tidy up” or “correct” the standard schema. This is a Bad Idea, as knowledge of the standard attributes is embedded in many widely used products. To make matters worse, many product authors have created their own overlapping or conflicting attribute sets to enrich the “addressbook experience”.
Fortunately, the better LDAP clients can be configured to use whatever attributes you want so it is often best to ignore the more broken parts of the standard set and create your own replacements. Some clients cannot cope with this, so it is worth finding out what you have to support and how flexible it is.
在LDAP RFC中出现的属性和object class有时候会显得非常尴尬。这一点儿都不奇怪，因为这些属性和object class是从不同的邮政电信标准演化而来的。随着新需求的出现，新的属性和object class被建立起来，这导致人们总是去试图整理和修正标准schema。这无疑是一个坏主意：因为标准attribute是作为一种约定俗成而嵌入到很多产品中。更为糟糕的是：很多产品的作者创建了只属于他们自己的属性集来丰富“addressbook experience”，而这些属性集经常会与标准属性集重叠甚至冲突。
幸运的是，比较好的LDAP客户端可以配置成可以使用任意的属性集，在这种情况下，自豪不要使用标准集中的那些“损坏的”部分，而自定义自己的属性集。某些客户端则不能做到自定义，那就必须花时间找出必须要支持的部分以及弹性如何。
3.3 Beware the Structural Object Class（留意结构性的object class）
Every entry has a Structural object class. This defines its fundamental characteristics, and cannot be changed once the entry has been created. If you define new attributes, or want to combine existing ones in new ways, you will need to create new object classes that allow this to happen. Most of the examples in the standards show this being done by subclassing existing object classes, but this creates problems. The LDAP standard diverged from X.500 just before the development of X.500 (1993), and has adopted parts of the later versions piecemeal. One of the later innovations was to split object classes into three types and to tighten the rules on how they could be combined. LDAP servers have now started to enforce these rules, and as a result the over-use of structural object classes can seriously limit the flexibility of a directory service.
所有的实体都拥有一个结构性的object class。这个object class定义了其基础属性。一旦该实体被建立，其object class不能被修改。如果你要定义新的属性，或者想把已经存在的属性重新组合，你需要定义新的object class才能实现。很多标准示例显示可以通过subclassing来实现，但是这会带来问题：LDAP起源于X.500的初始阶段而且采用了了很多X.500后来版本的特性。其中的最新的变革是将object class分为三类，而且规定了他们是否可以组合。LDAP服务器现在开始强制实行这些规则，这会导致结构性object class过多使用会严重限制目录服务的可扩展性。
I recommend that you pick a well-understood structural class for each type of entry, and then add Auxiliary object classes where needed. The rules for combining these are much simpler, and they can be added to existing entries or removed if desired. Some reasonable structural classes are:
Object Structural class
Person inetOrgPerson
Role organizationalRole
Department organizationalUnit
Organisation organization
你最好为每个实体选择一个容易理解的结构性object class，然后在需要的情况下添加辅助性的object class。针对组合的规则应该尽量做到简单，这样他们可以被加到已经存在的实体上，或者在需要的时候被移除。一些容易理解的结构性class如下：
4 DIT Layout
4.1 Top levels
The standards place very few restrictions on the form of the DIT, though if it is to be used with common client software there are some conventions that should be observed. There are two common forms used for the higher levels in the tree: geographic and domain-based. The geographic form was used in all examples in the original X.500 standards, as it is most suitable for global-scale “white pages” searching. Domain-based trees were introduced later, partly so that installers could avoid dealing with country-level registration authorities and partly to provide a simple way to map Internet domain names into the DIT. The two forms are shown in Figure 1.
DIT的形式，没有多少必须遵循的规范可言。如果一些普通的客户端软件来使用DIT的话，有一些约定需要注意。DIT的较高层次有两种常见形式：基于地理位置和基于域。在最初的X.500规范中，全部使用地理模式，这种模式比较适用于全球范围内的文本搜索。基于域的树出现的比较晚，这种树的一个有优点是：这样以来安装者可以处理国家层面的注册认证，另一方面可以提供一种将Internate域名映射到DIT的简单方法。
For an isolated directory system it makes little difference which form is chosen, though it is always wise to choose a base name that will not clash with any other directories that might get linked in future. The two forms can co-exist under the same virtual root if required. For most “internal” directory services, the Domain Component tree is the better choice. There is a direct mapping between DNS names and the upper levels of the tree, which allows the address of the LDAP server to be stored in the DNS and can make client configuration simpler. I generally recommend carrying the DC names down into the “local” part of the tree, as this makes it easier to divide the tree among several servers if required.
Our Example Organisation owns the domain name example.org so we will choose
ds.example.org as the base for the directory service. This translates to an LDAP suffix of dc=ds,dc=example,dc=org
对于一个独立的目录系统而言，选择什么形式影响不大。只要能保证名称不与未来可能有联系的目录系统不发生冲突即可。如果需要的话，两种形式可以在同一虚拟根目录下共存。对于大多数“网络”目录服务而言，基于域的树是比较好的选择。在DNS系统中保存的dns名称与树的较高层次存在映射的话，这样可以使得LDAP地址保存在dns中，从而使得客户端配置变得容易一些。强烈推荐将DC放到树的local部分，这样一来可以很容易在需要的情况下把一棵树分成几个独立的Server。
我们的示例组织拥有example.org的域名，因此，我们将会选择ds.example.org作为目录服务的基础。该域名翻译成LDAP前缀是dc=ds,dc=example,dc=org。