人们常说，使用 LDAP 是存储用户数据的好方法。这是因为用户的“目录”是分层的，并且很少更改。但在我看来，这并不排除使用 RDBMS。使用 LDAP 的原因可能是什么？我想在 LDAP 中存储多值字段或添加自定义字段可能更容易，但也可以在数据库中完成(除非你有很多记录)
最佳答案
正如已经提到的，互操作性非常有利于 LDAP 与某些类型的服务器软件，尽管与 LDAP 集成的许多软件都需要特定的模式，因此它不一定像安装和配置 LDAP 服务那样简单，然后关闭你去 - 你可能需要为你想要与之交互的每个应用程序在架构中添加新元素，并且每个应用程序在身份验证方面可能有不同的限制(例如纯文本密码字段，密码字段作为 MD5 或 SHA 哈希等)。
一个好的 LDAP 服务需要相当多的配置知识，而不是在关系数据库中创建一个简单的模式。 SQL DB 仍然是一个相当可互操作的选项，并且 LDAP 支持不再像以前那样占主导地位。 LDAP 在几年前曾经是唯一的选择，但许多应用程序(如 Apache)和操作系统(如 Linux 的 PAM)可以像 MySQL 一样轻松地对 SQL DB 进行身份验证，因为它全部由抽象接口(interface)的驱动程序处理。
LDAP 真正的亮点在于可扩展性。如果您特别想要一个地方来保存用户帐户以进行身份验证并希望扩展到多个复制的服务器 - 并且每秒处理数以千计的身份验证请求，那么 LDAP 是一个不错的选择。
并不是现代 RDBMS 无法扩展，而是 LDAP(通常)在这方面做得更好，因为它通过不同层级联复制的方式；特别是假设您有一个典型的身份验证数据库设置，其中它主要是只读的，写入操作相对较少，因此您只需要一种方式复制，所有写入都来自单一事实来源。
确实，如果您有特殊需要，可以考虑使用 LDAP 服务器，例如 。具体应用您希望能够与仅与 LDAP 集成的设备进行互操作，或 如果您正在构建一个高度可扩展的身份验证系统 (例如，对于 ISP 或 super 可扩展的 Web 应用程序 - 您计划拥有多个专门用于身份验证的服务器，并且它们可能分布在全国甚至全局)。
有人已经提出在 RDBMS 上拥有 LDAP 前端的观点非常好。一些公司——包括甲骨文(当然，他们对 RDBMS 有既得利益)——有专门做这件事的产品。如果您不希望管理 LDAP 服务的开销，或者如果您只想管理数据库中的所有用户，您可以创建 View /连接，但认为您以后可能需要 LDAP 服务，而不是一个不错的选择. OpenLDAP 还支持 shell 后端，它可以从任何来源(包括 RDBMS)接收数据；我已经将它与 MySQL 一起使用，它运行良好，但如果您需要支持特定的 LDAP 模式，第一次设置可能有点繁琐。
总之，LDAP 很棒，但它是特定于互操作性和极端可伸缩性的情况。如果您管理和支持的资源有限，则可能不值得麻烦，但如果您正在计划诸如 UNIX 托管 POP/IMAP/SMTP 或其他第三方软件集成之类的服务，那么它当然值得做(甚至可能成为您唯一可行的选择)。
哦，最后，如果您决定实现一个 LDAP 服务器，请注意您使用的 LDAP 服务器!它们并非都是平等的，它们之间的差异(在性能和易于管理和配置方面)可能非常明显。
OpenLDAP 是一个相当安全的选择，可以很好地扩展并且相当容易使用。某些应用程序运行得最好/带有特定 LDAP 服务器的特定配置文件(例如，Solaris 上的许多软件假定您使用的是 Sun ONE 目录服务器)，否则您可能不想使用这些文件 - 要么是因为它的性能不佳，或者是配置的 pig ，没有得到很好的支持等。
关于database - 将用户数据存储在 LDAP 而不是 RDBMS 中的原因，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2291833/