5

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

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

  1. 在目录服务器中建模分层数据比在 RDBMS 中更容易。

  2. 创建/定义扩展具有附加属性的基本类型的新实体类型也容易得多。从解决问题的角度来看，这是非常有吸引力的。

  3. 配置数据的读取频率将高于更新频率。尽管性能不是问题，但目录服务器非常适合此特性。

在对 LDAP 和目录服务器的基础知识进行了大约一周的引导之后，我现在对目录服务器的选择有些怀疑。我看到几个问题：

  1. LDAP 不如 RDBMS 主流。更多的人有过一些 SQL 的经验，并且可以比目录服务器更快地开始使用 RDBMS。正如我之前提到的，我花了一个多星期的时间来学习 LDAP 的基础知识（如何创建模式、定义 DIT、添加条目、将数据导出到 LDIF 文件等等）。这很重要，因为当新成员加入团队时，他/她不会面临学习曲线。

  2. 将来我们可能有更多的数据需要维护和存储在数据库中。目录服务器可能不是此类数据的好选择（例如，数据可能会随着读取的频率而更新）。在我看来，拥有两种存储机制是一种负担。

  3. 在更具政治性的方面，我不会因为选择 RDBMS 而受到指责/解雇，即使它不适合当前手头的问题。对于目录服务器，如果上面的第 2 点成为现实，我不想回答“你为什么不早点想到这一点？”这个问题。

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

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

  1. 第 2 点被认为比其他任何事情都重要。

  2. 我单位内部的想法似乎相当保守，各个级别的人都希望安全行事。不过我真的不能怪他们。

  3. “为什么不是 RDBMS？” 是第一个问题。“可以用 RDBMS 完成吗？” 是第二个。我终于收到消息了。

4

6 回答 6

4

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

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

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

  1. 所有 LDAP 都是相同的。它是一种访问协议而不是数据库实现，因此无论您的客户使用开源 LDAP 还是商业 LDAP，您的软件都不需要更改。

  2. 所有 RDBMS 都是不同的。无论您选择哪种 RDBMS，至少会有一个客户在不同的不兼容 RDBMS 上进行了标准化——如果您的产品相当成功，您最终将至少为 MySQL、Postgress、SQLServer、Oracle、DB2 和 Sybase 维护一个分支。

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

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

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

  1. 项目清单
于 2009-09-29T08:26:48.400 回答
1

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

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

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

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

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

于 2009-09-29T18:03:10.333 回答
0

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

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

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

于 2009-09-29T08:34:31.780 回答
0

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

于 2009-09-29T18:11:37.183 回答
0

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

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

于 2009-09-29T18:20:50.597 回答
0

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

如果你想走 DRBMS 路线，你可以使用 SQLite，但我实际上会选择第三种选择——XML 数据库。由于您已经在使用 XML，因此希望它可以轻松转换为像Berkeley DB XML这样的存储。您还可以查看 Wikipedia 以获取其他替代方案的列表

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

于 2009-09-29T21:12:47.430 回答