如何在LDAP和RDBMS之间划分责任

我是一个项目的首席开发人员，该项目正在为我的公司SaaS产品构建web应用程序。我们目前正在使用LDAP存储用户数据，如ID、密码、contanct详细信息、首选项和其他特定于用户的数据

我们正在构建的应用程序之一是一个报告服务，它将收集管理信息并将其呈现给最终用户。显然，该服务将需要一个RDBMS，但它还需要访问存储在LDAP中的用户数据

在我看来，我们有两个基本的实施方案：

LDAP和RDBMS中都存在重复的用户数据

让reporting service在需要用户数据时访问LDAP

尽管按照选项1中的建议复制数据（并实现实现这一点的机制）似乎是错误的做法，但我的直觉是，选项2的性能不够好（如何将LDAP数据“连接”到RDBMS数据，使其与纯RDBMS实现一样高效？）

---

我确实找到了一个方法，但我仍然不确定该采取哪种方法。我很想看看人们对这两个选项或其他选项的看法。

为什么你会觉得复制数据是错误的做法？报告工具（基于web或其他）大多是围绕RDBMS构建的，因此任何混合匹配都会带来不必要的复杂性。报告可能需要相当频繁地更改（根据经验），因此您希望它们尽可能简单。您存储的有关用户的数据不太可能经常更改其格式，因此，一旦导入功能正常工作，就不需要再次触摸它

我能看到的唯一障碍是延迟：如何确保RDBMS副本是最新的？您可能需要确保更新代码同时写入两个目标。就个人而言，我也不一定要将LDAP用于特定于应用程序的个人首选项：LDAP不能处理事务，所以当数据从多个方向更新时会发生什么？（让更新程序同时写入两个存储当然也是事务性的问题…）我宁愿让RDBMS成为大多数数据的主数据库，让LDAP只关心身份、凭证和权限，这些信息很少更改，而且只用于一组目的。对我来说，LDAP处理分层数据的能力并不是一个很好的卖点

---

数据复制并不总是一件坏事，尤其是在使用场景差异很大的情况下

这是一个问题的示例，我们可以在其中实现用户登录报告。我们需要一个登录事件列表和一些相关的用户数据，如显示名称和电话号码。登录事件将存储在RDBMS中，但用户数据将存储在LDAP中。