Database 存储用户的原因'；LDAP中的数据，而不是RDBMS

人们常说，使用LDAP是存储用户数据的好方法。这是因为用户的“目录”是分层的，很少改变。但在我看来，这并不排除使用RDBMS。使用LDAP的原因可能是什么？我想在LDAP中存储多值字段或添加自定义字段可能更容易，但也可以在数据库中完成（除非您有许多记录）

一个很好的理由是在许多应用程序（使用LDAP）中提供单点登录。

LDAP中的“L”代表轻量级。LDAP的一个目标是使用和实现相对简单。如果您只需要存储有关用户的信息，那么就不需要通过SQL访问数据的全部灵活性（以及潜在的麻烦）。LDAP提供的有限接口应该更容易。如果您希望人人（包括您的操作系统供应商和所有应用程序供应商）都能实现和支持LDAP，这一点非常重要

PS：如果您愿意，您可以通过将所有信息存储在RDBMS中并向其提供LDAP接口来实现LDAP服务器：）

PPS:LDAP是一种协议，与HTTP类似。RDBMS是一种应用程序，通常被认为是实现SQL等功能的应用程序。因此，要对苹果进行比较，最好将LDAP与SQL或HTTP进行对比。

互操作性

LDAP目录有一个标准的模式来表示用户，因此在不同的目录实现中，诸如名字、姓氏和电子邮件地址等公共字段的命名将是一致的。RDBMS并非如此

LDAP定义了通信协议和查询语言。与SQL相比，SQL只是一种查询语言，每个RDBMS都实现自己的通信协议

---

因此，有很多应用程序可以简单地“插入”到LDAP目录作为用户存储，从而允许您集中用户管理。（当然，目录实现之间仍然存在兼容性问题，但与将用户存储在每个应用程序的单独数据库中相比，这些问题显得微不足道）。

如前所述，对于某些类型的服务器软件，互操作性非常有利于LDAP，尽管许多与LDAP集成的软件都需要特定的模式，因此它不一定像安装和配置LDAP服务那样简单，您可能需要为要与之交互的每个应用程序在模式中添加新元素，每个应用程序在身份验证方面可能有不同的限制（例如纯文本密码字段、MD5或SHA哈希等密码字段）

一个好的LDAP服务需要相当多的配置知识，而不是在关系数据库中创建一个简单的模式。SQL DB仍然是一个相当可互操作的选项，LDAP支持也不像以前那样占主导地位。几年前，LDAP曾经是唯一的选项，但许多应用程序（如Apache）和操作系统（如Linux的PAM）可以通过SQL DB（如MySQL）进行身份验证，就像LDAP服务器一样简单，因为所有这些都是由抽象接口的驱动程序处理的

LDAP真正闪耀的地方是可伸缩性。如果您特别希望有一个地方存放用于身份验证的用户帐户，并且希望扩展到多个复制服务器，并且每秒处理数千个身份验证请求，LDAP是一个很好的选择

并不是现代的RDBMS不能扩展，只是LDAP（通常）在这方面做得更好，因为它通过不同的层级联复制；特别是假设您有一个典型的身份验证数据库设置，其中大部分是只读的，写操作相对较少，因此您只需要单向复制，所有写操作都来自一个真实来源

实际上，LDAP服务器是一个需要考虑的事情，如果您有特定的需求，比如<强>特定的应用程序<强>，您希望能够与只与LDAP集成，或者<强>的互操作，如果您正在构建一个高度可扩展的认证系统>（例如，对于ISP或超级可扩展的web应用程序，您计划拥有多台专用于身份验证的服务器，并且这些服务器可能遍布全国甚至全球）

有人已经提出了在RDBMS上安装LDAP前端的观点，这一点非常好-有专门这样做的产品。如果您不想管理LDAP服务的开销，或者您只想管理数据库中的所有用户，您可以创建视图/连接，但认为以后可能需要LDAP服务，这是一个不错的选择。OpenLDAP还支持shell后端，它可以接收来自任何源的数据，包括我在MySQL中使用过RDBMS，它工作得很好，不过如果需要支持特定的LDAP模式，第一次设置时可能会有点麻烦

总之，LDAP很好，但它是特定于互操作性和极端可扩展性的情况。如果您管理和支持LDAP的资源有限，那么可能不值得为其提供支持，但如果您正在规划诸如UNIX托管的POP/IMAP/SMTP或其他第三方软件集成之类的服务，那么这当然值得一做（甚至可能是你唯一可行的选择）

哦，最后一点，如果您决定实现LDAP服务器，请注意您使用的LDAP服务器！它们并非都是相同的，它们之间的差异（在性能和管理与配置的易用性方面）可能非常明显

OpenLDAP是一种非常安全的选择，具有良好的可扩展性，并且非常易于使用。某些应用程序工作得最好/附带特定LDAP服务器的特定配置文件（例如，Solaris上的许多软件假定您使用的是Sun ONE directory server），其中