在目录服务器（也称为 LDAP 数据库）和 RDBMS 之间进行选择答案

【问题标题】：Choosing between a directory server (a.k.a LDAP database) and an RDBMS在目录服务器（也称为 LDAP 数据库）和 RDBMS 之间进行选择
【发布时间】：2010-12-02 05:57:26
【问题描述】：

在我作为首席开发人员的项目中，我们之前有一个存储单个 XML 文件的网络配置。配置包含有关网络布局的信息 - 其组成主机，有关每个主机的各种详细信息，如操作系统、平台、在每个主机中配置的用户、每个用户的多个属性等等。在即将发布的产品版本中，我们希望将数据移动到某种数据库中，因为配置将被扩展以包含更多元素和细节，并且在 XML 文件中维护它们将变得很麻烦。

第一个选择是 RDBMS。然而，由于配置数据的分层性质和可扩展性标准，目录服务器似乎是更好的选择。使用目录服务器的动机是

在目录服务器中建模分层数据比在 RDBMS 中更容易。
创建/定义使用附加属性扩展基本类型的新实体类型也容易得多。从解决问题的角度来看，这非常有吸引力。
配置数据的读取频率将高于更新频率。虽然性能不是问题，但目录服务器非常适合此特性。

经过大约一周的 LDAP 和目录服务器基础知识的自我引导之后，我现在对目录服务器的选择有些怀疑。我发现了一些问题：

LDAP 不如 RDBMS 主流。更多的人有过一些 SQL 的经验，并且可以比目录服务器更快地开始使用 RDBMS。正如我之前提到的，我花了一个多星期的时间来学习 LDAP 的基础知识（如何创建模式、定义 DIT、添加条目、将数据导出到 LDIF 文件等等）。这很重要，因为当新成员加入团队时，他/她不会面临学习曲线。
将来我们可能有更多的数据需要维护和存储在数据库中。目录服务器可能不是此类数据的好选择（例如，数据可能会随着读取的频率而更新）。在我看来，拥有两种存储机制是一种负担。
在更具政治性的方面，我不会因为选择 RDBMS 而受到指责/解雇，即使它不适合当前手头的问题。对于目录服务器，如果上述第 2 点成为现实，我不想回答“你为什么不早点想到这一点？”这个问题。

我正在寻找有关如何做出选择的建议。有没有人遇到过类似的情况？

EDIT-1：我们在项目中对此进行了讨论，我提出了我在这里提出的确切观点。由于以下原因，我们很可能会选择不做任何进一步评估的 RDBMS：

第 2 点被认为比其他任何事情都重要。
我单位内部的想法似乎相当保守，各个级别的人都希望安全行事。不过我真的不能怪他们。
“为什么不用 RDBMS？”是第一个问题。 “可以用 RDBMS 完成吗？”是第二个。我终于收到消息了。

【问题讨论】：

这种部署方式是否使 LDAP 或 RDBMS 完全在您的产品内部，而客户不会知道其中的区别？还是希望客户使用他们现有的数据库或 LDAP？我问是因为一些管理员非常不愿意更改其核心 LDAP 服务器的架构。
是的，这完全是内部的。

标签： rdbms choice directory-server

【解决方案1】：

通常我会尽快逃离 LDAP，但是您只是调用了使 LDAP 成为更好选择的两个魔术短语“配置数据的层次结构”和“配置数据”。

LDAP 专为这种（并且仅用于这种）类型的数据而设计。

选择 LDAP 还有其他更实际的原因。

所有 LDAP 都相同。它是一种访问协议而不是数据库实现，因此无论您的客户使用开源 LDAP 还是商业 LDAP，您的软件都不需要更改。
所有 RDBMS 都不同。无论您选择哪种 RDBMS，至少会有一个客户对不同的不兼容 RDBMS 进行了标准化——如果您的产品相当成功，您最终将至少为 MySQL、Postgress、SQLServer、Oracle、DB2 和 Sybase 维护一个分支。

如果您的客户/老板抱怨它不像 ORACLE/DB2 那样防弹/高性能/事务性，请指出客户可以选择使用 ORACLE 或 DB2 的 LDAP 实现。

唯一真正的缺点是缺乏 LDAP 经验。大多数开发人员对 LDAP 的唯一体验是使用 J2EE 附带的默认用户安全模式。

LDAP 模式是数据库，需要像管理和变更控制程序这样的数据库！

列表项

【讨论】：

【解决方案2】：

如果您只是在寻找更改配置数据库，RDBMS 是您的最佳选择。这是一个常见的 IT 问题，并且有各种商业解决方案。在大量投资定制解决方案之前，不妨先看看现有的情况。

如果您希望最终整合跨多个平台（windows / linux / 等）的集成身份验证，那么 LDAP 是不二之选。不仅大多数服务器和桌面操作系统本身支持 LDAP 身份验证，而且 LDAP 可以轻松地集群或跨多个站点同步。

您很可能最终会得到一个混合解决方案。您的大部分变更控制数据库 (CCDB) 可以驻留在 RDBMS 中，但身份验证可以通过 LDAP 集群提供服务。统一的前端可以管理两者中的信息。避免在您的 CCDB 中保留帐户密码，出于安全原因，请改用 LDAP。

无论您使用 RDBMS 还是 LDAP，您都可能编写包装脚本、应用程序或基于 Web 的前端来在您的 CCDB 中添加/更新信息。这有助于缩短新员工的学习曲线，并简化和控制变更控制数据库的更新。

不要低估将新员工指向原始 RDBMS 并希望获得最佳结果的风险。综合 CCDB 的架构可能非常复杂，无论您选择哪种技术对其进行建模。

【讨论】：

【解决方案3】：

出于以下原因，我会采用 RDBMS 方法：

您可以轻松修改和扩展其结构。
如果您正在建模的网络与我的网络相似，那么尝试以分层方式对其进行建模将是一场灾难。（本质上不是。）。例如防火墙规则、服务器访问其他服务器、子网等。
报告非常容易。
比 LDAP 更容易找到精通 SQL 的开发人员。
满足特殊情况相对容易，这在 LDAP 中可以轻松完成吗？

话虽如此，我更熟悉 RDBMS 方法，所以我有偏见。

【讨论】：

【解决方案4】：

答案很简单：如果您需要目录，请使用 LDAP。如果您需要数据库，请使用 RDBMS。由于您的目标是拥有类似目录的结构（听起来很像“电话簿”），因此请使用 LDAP。 RDBMS 对您的需求来说开销太大。

【讨论】：

我真正的意思是不要想太多。 :)

【解决方案5】：

我不确定“没有人因为……而被解雇”的说法是否适用于此。毕竟，您确实需要一个目录服务器，我们不是在谈论位于想象中的 LDAP 数据库轴中间的请求。

我肯定会选择 LDAP，尽管我不能把自己放在一个可能会因为选择目录服务器解决方案来匹配目录服务器问题而被解雇的人的立场......

【讨论】：

【解决方案6】：

由于您的数据结构，我倾向于使用 LDAP，尽管如此，我认为需要更多的人来处理分层数据库并远离“RDBMS是唯一的数据库”心态，我不知道您可以将一个易于移植的 LDAP 服务器嵌入到更大的应用程序中。

如果你想走 DRBMS 路线，你可以使用 SQLite，但我实际上会选择第三种选择——XML 数据库。由于您已经在使用 XML，因此希望它可以轻松切换到类似 Berkeley DB XML 的存储空间。你也可以在维基百科上查看list of other alternatives

（以及免责声明——我从未使用过任何 XML 数据库；我在 LDAP 端使用过 OpenLDAP、iDS 和 eDirectory，在 RDBMS 端使用过 Oracle、SQL Server、mySQL、PostgreSQL、SQLite 等）

【讨论】：