9

在我工作过的每一家大公司中，他们都使用 LDAP 作为访问用户信息中央存储库的一种方式，但是很少有人努力扩展模式以包含不是从 inetOrgPerson 派生的 objectClasses。

Microsoft 的 Active Directory 进行了广泛的模式扩展，但很少有商业产品利用 LDAP 的功能。

是因为大多数 LDAP 开发人员不知道如何在用户之外建模吗？在其中找到价值，但还没有深入思考？尝试过并遇到性能问题？别的东西？l

4

5 回答 5

5
  • 我一直认为 LDAP对于网络管理员来说级别太高，而对于软件开发人员来说级别太低。他们俩似乎都对此感到不自在。
  • 有一种看法是，由于几乎每个企业应用程序都将使用关系数据库，因此添加一个数据源会降低应用程序的可用性和可靠性。
  • 在 LDAP 中创建自定义模式的障碍仍然很高。在 LDAP 服务器中，您必须将架构文件放在架构目录中，通常使用 root 或管理权限重新启动 LDAP 服务器；而当前的 ORM 可以在应用程序启动时创建、更新或验证关系数据库模式。
于 2009-04-04T12:22:54.900 回答
4

我个人认为这是因为 LDAP 是一个目录，而不是数据库。目录有利于查找人员及其相关数据，但它们对于跟踪高度相关的数据并不是特别好——这就是我们其他大部分数据的样子。事实上，我们对 LDAP 的使用实际上是作为“人”数据的前端，将大量数据流合并到单个目录视图中。我们仍然在后端数据库中拥有“人员”数据以及我们的其他机构数据，并且只选择 LDAP（在我们的例子中为 ADAM）作为前端，以便方便地查找合并的“人员”数据。现在我们正在转向使用 Web 服务作为访问这些数据的一种方式，我不确定继续使用 LDAP 路由是否有意义（除了支持尚未更新的现有服务）。

于 2009-04-04T12:34:15.903 回答
3

我们已经为一些拥有 6500 万条 LDAP 记录的公司完成了工作，但这些记录都不是针对人的。

数据是主要用于设备的各种项目，包括：* DHCP * DNS * Mac 地址 * 位置 * SN * 品牌 * 型号 * 等....

-吉姆

于 2009-04-07T14:10:11.403 回答
2

我认为这是由于 A）使用 LDAP 的复杂性（远高于 SQL）和 B）您的产品将完全与之绑定的事实。也就是说，它在运行 LDAP 的大型组织之外没有市场。用更少的钱和精力，我可以构建一个可以在任何地方运行的应用程序。

现在，专门为需要访问其他 LDAP 数据的组织编写的内部应用程序是另一回事。但是您显然会很少听到有关它们的信息，因为它们没有进行商业销售。

于 2009-04-04T12:09:22.577 回答
0

我认为 LDAP 针对快速、频繁的读取进行了高度优化。我认为它们不会扩展到事务系统。

关系模型及其在 SQL 中的表达是一个强大的东西。我认为它不会被 LDAP 或对象数据库轻易取代。

于 2009-04-04T15:50:03.933 回答