除了用户/身份验证信息之外，目录服务中还应该存储什么？

Question

This excellent answer 解释了 LDAP/Directories 相对于 RDBMS 的优势在适当的情况下，但仅提及用户帐户和以身份验证为中心的信息作为存储在目录中的数据类型。

答案基本上将以下优点归功于目录：

• 针对超快速读取进行了调整，这是身份验证系统的典型特征
• 可扩展性
• 大多数 RDBMS 都不容易实现的开箱即用的复制功能
• 互操作性

我想知道其他 用例可能需要将数据存储在目录中。如果读取性能是主要优势，那么我认为任何 OLAP 存储都可能是不错的选择，例如数据仓库或报告生成系统。

但是我在 LDAP 和目录方面的经验非常有限，我很难看到“树林中的森林”；我只见过存储在目录中的用户数据，例如：

DC=示例，DC=org，OU=客户服务，CN=John Smith

我不完全确定这将如何转化为存储/查询非用户数据。

有人能告诉我，除了用户/身份验证系统之外，哪些用例是存储在目录中的主要候选者，和提供一个或两个条目的外观示例在目录中，以便我可以思考如何存储/组织非用户数据？

Answer 1

我的包含：

• 用户
• 角色
• 密码政策
• 系统使用的电子邮件帐户条目
• 服务器主机条目
• VM 来宾的条目，排列在各自的主机下
• 服务器软件模块的条目，例如Apache HTTPD、Tomcat、MySQL、OpenLDAP 本身、SSH 等，以及它们的复制从属（如果适用），显示它们的公共 URL，排列在各自的主机或来宾下。
• 上一项还包括我们的邮件服务器，它由 ISP 外部运营，其 SMTP 和 POP3 端口的 URL 以及 Webmail 接口的 URL，这种东西太容易忘记了。
• 网络和子网条目
• 我们经营所在国家/地区的条目以及这些国家/地区的部门

换句话说，除了用户/身份验证信息之外，还有很多东西：

• 自然分层
• 非交易性
• 主要是指示性的
• 可能根本不会存储在数据库中，并且
• 可以受益于在一个地方组织和可见，受备份和复制等影响。

我还有一个站点本身的条目，包含它的标题 &c 以显示在网页上。

我还有一个产品的子树，显示它们的相互关系和物料清单：我们的系统实际上并没有目录本身，但它确实需要通过网络分层探索页。这些产品实际上是documentSeries,，每个产品都拥有一个或多个documents,，并带有URL。这实际上是为了组织网站，而不是到处种植链接。

我还将它用作某些实验室设备的清单，这些设备也不会出现在数据库中。

而且我不必编写单个表架构。