LDAP SCHEMA DESIGN(二)

2 Requirements
When considering an LDAP deployment that is to serve more than one application, it is important to get the widest possible view of the host organisation and its future needs. This is because it is easy to change the shape of the DIT at the design stage but very hard once data has been loaded and applications are running.
一旦意识到一个LDAP部署将会为多个应用提供服务时，就必须从尽可能宽泛的视角来进行组织管理和特性需求。因为DIT的设计在设计阶段修改起来时很容易的，但是一旦数据已经导入进去或者应用已经启动的话，修改起来就会十分困难。
2.1 The Example Organisation
Consider a hypothetical organisation called The Example. It has a domain name example.org and wants to integrate several systems that handle data relating to people. The services required are:
假设有这样一个被称为The Example的组织，该组织的域名为example.org，该组织要求整合与人员信息相关的多个系统。该服务需求罗列如下：
White Pages searches for People and Roles, from several existing user interfaces?? Authentication - simple (e.g. web portal) and with extra data (e.g. Samba for Windows clients and Unix NSS/PAM)?? Authorisation - groups of various sorts, permissions, access-control for particular applications
?? Storage of application-specific data - config, personalisation, mapping tables
?? Integration of mail-system configuration with White Pages directory It is certainly possible to meet all these requirements with a single LDAP-based directory,
though it will need some careful thought about how the data is to be managed.
基于现有的用户接口，进行针对人员及角色信息的文本搜索。
授权，简单授权和带有附加数据的授权。
鉴权，不同组别对特定程序的访问控制。
保存应用程序相关数据：配置数据，个性化数据，表单映射。
将邮件系统配置与文本目录集成。
通过认证的规划数据，通过一个单独的LDAP目录满足以上需求是可能的。

3 LDAP issues and design principles
3.1 Avoid renaming things（避免重新命名）
Once an object has been created in an LDAP directory it is likely that the name of that object will get stored in other objects, or even outside the directory entirely. This suggests that objects should never be renamed, which in turn restricts the choice of how they should be named in the first place.
在LDAP目录中，对象一旦被创建，这就意味着这个对象被存储在其他对象的内部，或者是目录实体中。因此对象不应该被重新命名，换句话说如何为对象选择名称是首要问题。
Most of the examples in the X.500 and LDAP standards documents use “natural” names for objects. Thus the object representing a person is usually shown with an RDN based on the person's name. This leads to two problems: what to do if the person changes their name, and how to cope with several people who happen to share the same name. The “standard” approach to the name-clash problem is to use an extra attribute in the RDN to remove the ambiguity. Thus, multiple Fred Smiths end up with RDNs of the form “cn=Fred Smith + uid=67354”. This does not solve the name-change problem though, so I recommend that all entries representing people
or other entities that might change name should be given RDNs containing only the
uniqueIdentifier attribute: the value can be a simple serial number, which does not have to mean anything outside the directory.
在大多数X.500和LDAP标准文档中，都是采用对象的“自然”名称。比如代表人的对象的RDN通常就是此人的名字。这会导致两个问题：如果需要改名怎么办？重名怎么办？针对名字冲突的标准解决方案是加上附加属性以消除模糊性。因此，多个Fred Smith应该采用以类似于““cn=Fred Smith + uid=67354”结尾的RDN。但这仍然无法解决名称改变的问题，为了解决这一问题，我们可以提出这样一个原则：代表人员及其他可能改名的实体应该采用包含唯一标识的RDN。该唯一标识可能是一串数字，这串数字在目录之外毫无意义。
There is a potential problem with this approach too: some directory user interfaces use the RDN value to title the entry display. A meaningless serial number would look odd when used for that purpose. Fortunately this behaviour is now rare, and the standards provide an attribute that is explicitly intended for the job: displayName. It is thus a good idea to include displayName in every directory entry.
但是这种方法也有一个潜在的问题：一些目录使用接口使用RDN作为实体展示的title，毫无意义的数字序列看起来非常奇怪。幸运的是这种行为现在已经很少见了，展示用的title应该使用一个显式属性：displayname。因此最好在每个目录实体中都包含一个displayname。