代码之家  ›  专栏  ›  技术社区  ›  trshiv

在目录服务器(也就是LDAP数据库)和RDBMS之间进行选择

  •  5
  • trshiv  · 技术社区  · 17 年前

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

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

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

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

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

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

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

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

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

    我在寻找如何做出选择的建议。以前有人遇到过类似的情况吗?

    编辑1 : 我们在项目中对此进行了讨论,我在这里提出了我在这里提出的确切观点。由于以下原因,我们很可能选择一个RDBMS而不进行任何进一步的评估:

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

    2. 我所在部门的想法似乎相当保守,所有级别的人都希望安全。但我真的不能怪他们。

    3. “为什么不是RDBMS?”是第一个问题。”能用RDBMS完成吗?”是第二个。我终于明白了。

    6 回复  |  直到 17 年前
        1
  •  4
  •   James Anderson    17 年前

    通常,我会尽可能快地离开LDAP,但是您只是调用了两个神奇的短语,使LDAP成为更好的选择。 “配置数据的层次结构性质” 以及“配置数据”。

    LDAP是为这种类型的数据而设计的。

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

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

    2. 所有RDBMS都不同。 无论您选择哪种RDBMS,至少会有一个客户在不同的不兼容RDBMS上实现了标准化——如果您的产品相当成功,那么您最终将为至少mysql、postgress、sqlserver、oracle、db2和sybase维护一个fork。

    如果您的客户/老板抱怨它不像Oracle/DB2那样防伪/性能/事务性,那么指出客户可以选择使用Oracle或DB2的LDAP实现。

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

    LDAP模式是数据库,需要像管理和更改控制过程这样的数据库!

    1. 列表项
        2
  •  1
  •   ives    17 年前

    如果您只是在寻找一个变更配置数据库,那么RDBMS就是一种方法。这是一个常见的IT问题,有各种商业解决方案。在大量投资于定制解决方案之前,可能值得先看看外面有什么。

    如果您希望最终在多个平台(windows/linux/etc)上集成集成身份验证,那么LDAP就是一种方法。大多数服务器和桌面操作系统不仅支持本地LDAP身份验证,而且可以轻松地跨多个站点集群或同步LDAP。

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

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

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

        3
  •  0
  •   Bravax    17 年前

    我将使用RDBMS方法,原因如下:

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

    尽管如此,我更熟悉RDBMS方法,所以我有偏见。

        4
  •  0
  •   Andrew Sledge    17 年前

    答案很简单:如果需要目录,请使用LDAP。如果需要数据库,请使用RDBMS。因为您的目标是拥有一个类似目录的结构(听起来很像“电话簿”),所以使用LDAP。RDBMS对于您需要的东西来说开销太大了。

        5
  •  0
  •   user15486    17 年前

    我不确定“没人因为……”这个论点是否适用。毕竟,您确实需要一个目录服务器,我们并不是在讨论一个位于可想象LDAP数据库轴中间的请求。

    我肯定会选择LDAP,虽然我不能让自己成为一个可能因为选择目录服务器解决方案来匹配目录服务器问题而被解雇的人…

        6
  •  0
  •   Joe    17 年前

    由于您的数据结构,我倾向于使用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等)

    推荐文章