我非常熟悉关系建模，但对LDAP建模不熟悉，我正在寻找设计LDAP模式的最佳实践。很想知道LDAP世界中第三范式和其他实践的等价物是什么？
非常感谢关于此主题扩展的白皮书的链接。
答案 0 :(得分：9)
选择适合您预期目的的标准架构，例如core，cosine，inetOrgPerson，eduPerson，Java Objects，etc. 。大多数LDAP服务器都附带一组默认值。
首选现有元素，但如果需要extend the schema，请使用comCompany（您公司的域名或其他唯一标识符）作为前缀，以避免与未来的标准元素发生冲突。
答案 1 :(得分：4)
我们的经验表明架构的设计和DIT非常依赖于LDAP服务器的目的。
对于架构，通常最好坚持使用行业或LDAP服务器供应商的“标准”。
对于DIT的结构，除非用于文件和打印服务（即Active Directory）或OES（Netware），否则通常“平面”结构可以更好地扩展。
如果它是一个大型实现（即>> 100k），那么应尽可能避免使用组。
-Jim
答案 2 :(得分：3)
根据我的经验尽可能地反规范化，如前所述，使用LDAP的目标是非常快速的查找，但这意味着记录的插入可能需要更长时间。确保您可以保留ldap的备份也很重要。
您可能希望查看创建各种类，例如用户，但如果需要，还可以为授权用户创建一个类。
看看可能需要什么。例如，在我所在的大学，我们意识到一些只与该大学有切合关系的人将拥有一个LDAP帐户。
当您确定ldap中将包含哪些类型的用户或资源时，它将帮助您确定如何设置人员。例如，如果您有一个只是用户名或标识符和密码的类，也许还有证书，那么灵活性会有所帮助。
如果您要允许人们从他们的unix帐户登录，那么某些类必须位于架构中。
答案 3 :(得分：2)
LDAP本质上 NOT 符合第一范式 - 其某些属性可以包含多个值。
LDAP是专为实现最佳读取/查找性能而设计的系统，例如：它更适合于您更多地阅读/查找数据的方式（ - ＆gt;目录;您的公司电话簿每天不会更改数十次）。
LDAP不适合或旨在替换或竞争标准关系数据库系统，该系统在数据输入/转换方面表现优异，其中大量操作将插入和/或更新数据。这就是RDBMS非常适合的。
所以，最后：LDAP与RDBMS实际上并非一个非首发 - 而且这两个世界在工作方式上截然不同且完全不同。我不建议尝试盲目地将一个世界的东西应用到另一个世界 - 这将是一场糟糕的比赛。
至于LDAP模式设计的灵感 - 我肯定会看看微软的Active Directory，Novell的eDirectory（或者其他所谓的目录），以及其他可能的LDAP目录，并从他们的设计中学习。
马克