Database 将用户数据存储在 LDAP 而不是 RDBMS 中的原因

正如前面已经提到的，在某些类型的服务器软件中，互操作性非常有利于LDAP，尽管许多与LDAP集成的软件需要特定的模式，因此它不一定像安装和配置LDAP服务就可以开始那样简单-您可能需要在模式中为您想要与之交互的每个应用程序添加新元素，并且每个应用程序在身份验证方面可能有不同的限制(例如，纯文本密码字段、MD5或SHA散列等密码字段).

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

LDAP真正闪耀的地方是可伸缩性.如果您特别想要一个存放用户帐户以进行身份验证的地方，并且希望扩展到多个复制的服务器，并且每秒可以处理数以千计的身份验证请求，那么LDAP是一个很好的 Select .

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

不过，如果您有特定的需求，例如您希望能够与LDAP进行互操作的specific application或if you are building a highly scalable authentication system(例如，对于ISP或超级可伸缩的Web应用程序-您计划拥有多台专用于身份验证的服务器just，并且它们可能分布在全国甚至全球)，那么LDAP服务器确实是需要考虑的.

有人已经提出了在RDBMS上安装LDAP前端的观点，这一点非常好.一些公司-包括甲骨文(当然，甲骨文在RDBMS中有既得利益)-有专门做这件事的产品.如果您不想要管理LDAP服务的开销，或者如果您只想管理数据库中的所有用户，您可以使用它来创建视图/连接，但又认为以后需要LDAP服务，那么这是个不错的 Select .OpenLDAP还支持一个shell后端，它可以接收来自任何源(包括RDBMS)的数据；我已经将它与MySQL一起使用过，它工作得很好，尽管如果您需要支持特定的LDAP模式，第一次设置可能会有点麻烦.

总而言之，LDAP很棒，但它是特定于互操作性和极端可伸缩性的情况.如果您要管理和支持的资源有限，可能不值得麻烦地支持它，但是如果您正在计划像UNIX托管的POP/IMAP/SMTP或其他第三方软件集成这样的服务，那么它肯定是值得做的(甚至可能是您唯一可行的 Select ).

哦，最后，如果您确实决定实现LDAP服务器，那么一定要小心您使用的LDAP服务器！它们并非生来就是平等的，它们之间的差异(就性能和管理与配置的简易性而言)可能相当明显.

OpenLDAP是一个非常安全的 Select ，伸缩性很好，并且相当容易使用.有些应用程序为特定的LDAP服务器(例如，Solaris上的许多软件假定您使用的是Sun ONE目录服务器)提供了特定的配置文件，您可能不想使用这些配置文件，因为它的性能不佳，或者配置起来很麻烦，不受很好的支持，等等.