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

Question

This excellent answer在正确的情况下解释了LDAP /目录优于RDBMS 的优点，但仅提到用户帐户和以身份验证为中心的信息作为要存储在目录中的数据类型

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

• 调整为超快速读取，在auth系统中是典型的
• 可扩展性
• 大多数RDBMS无法轻松实现的复制功能
• 互操作性

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

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

  

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

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

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

Answer 1

我的包含：

• 用户
• 角色
• 密码政策
• 系统使用的电子邮件帐户的条目
• 服务器主机的条目
• VM guest虚拟机的条目，安排在各自的主机下
• 服务器软件模块的条目，例如Apache HTTPD，Tomcat，MySQL，OpenLDAP本身，SSH等，以及适用的复制从站，显示其公共URL，安排在各自的主机或访客下。
• 上一项还包括我们的邮件服务器，该服务器由ISP在外部操作，其SMTP和POP3端口以及Webmail界面的URL很容易让人忘记。
• 网络和子网的条目
• 我们经营所在国家/地区以及这些国家/地区的分部

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

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

我还有一个网站本身的条目，其中包含标题＆amp; c，用于在网页上显示。

我还有一个产品子树，显示它们之间的相互关系和物料清单：我们的系统本身并没有真正的目录 但它确实需要通过层次结构来探索一个网页。这些产品实际上documentSeries,每个网站都会再次拥有一个或多个documents,。这实际上用于组织网站，而无需在任何地方种植链接。

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

我没有必要编写单个表架构。