如何在 LDAP 和 RDBMS 之间划分职责
我是一个项目的首席开发人员，该项目正在为我公司的 SaaS 产品构建 Web 应用程序。我们目前使用 LDAP 来存储用户数据，例如 ID、密码、联系人详细信息、首选项和其他用户特定数据。
我们正在构建的应用程序之一是报告服务，它将收集并向最终用户提供管理信息。显然，该服务需要 RDBMS，但它还需要访问存储在 LDAP 中的用户数据。
在我看来，我们有两个基本的实现选项：
- 在 LDAP 和 RDBMS 中复制用户数据。
- 让报告服务在需要用户数据时访问 LDAP。
尽管按照选项 1 中的建议复制数据（并实现实现这种情况的机制）似乎是错误的方法，但我的直觉是选项 2 的性能不够好（如何将 LDAP 数据“连接”到 RDBMS 数据，如作为纯 RDBMS 实现是否高效？）。
我确实找到了相关问题但我仍然不确定采取哪种方法。我有兴趣了解人们对任一选项或其他选项的看法。
I'm a lead developer on a project which is building web applications for my companies SaaS offering. We are currently using LDAP to store user data such as IDs, passwords, contanct details, preferences and other user specific data.
One of the applications we are building is a reporting service that will both collect and present management information to our end users. Obviously this service will require a RDBMS but it will also need to access user data stored in LDAP.
As I see it we have a two basic implementation options:
- Duplicate user data in both LDAP and the RDBMS.
- Have the reporting service access LDAP whenever it needs user data.
Although duplicating data (and implementing the mechanisms to make this happen) as suggested in option 1 seems the wrong way to go, my gut feeling is that option 2 would not perform well enough (how do you 'join' LDAP data to RDBMS data as efficiently as a pure RDBMS implementation?).
I did find a related question but I'm still unsure which approach to take. I'd be interested in seeing what people thought of either option or perhaps other options.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
为什么您认为复制数据是错误的方法？报告工具（基于网络的或其他的）主要是围绕关系数据库管理系统构建的，因此任何混合都会引入不必要的复杂性。报告可能需要相当频繁地更改（根据经验），因此您希望它们尽可能简单。您存储的有关用户的数据不太可能经常更改其格式，因此一旦您的导入功能正常工作，您就不需要再次触及它。
我看到的唯一障碍是延迟：如何确保 RDBMS 副本是最新的？您可能需要确保更新代码写入两个目标。就个人而言，我也不一定将 LDAP 用于特定于应用程序的个人偏好：LDAP 无法处理事务，那么当数据从多个方向更新时会发生什么？ （事务性当然也是让更新程序写入两个存储的一个问题......）我宁愿让 RDBMS 成为大多数数据的主人，并让 LDAP 只担心身份、凭证和权利，这些很少被更改并且仅用于一组目的。对于我自己来说，LDAP 处理分层数据的能力并不是一个很好的卖点。
数据重复并不总是坏事，尤其是当使用场景足够不同时。
Why would you feel that duplicating data would be the wrong way to go? Reporting tools (web based and otherwise) are mostly built around RDBMS's, so any mix'n'match will introduce unnecessary complexities. Reports are likely to need to be changed fairly frequently (from experience), so you want them to be as simple as possible. The data you store about users is unlikely to change its format very often, so once you have your import function working, you won't need to touch it again.
The only obstacle I can see is latency: how do you ensure that your RDBMS copy is up to date? You might need to ensure that your updating code writes to both destinations. Personally, also, I wouldn't necessarily use LDAP for application specific personal preferences: LDAP can't handle transactions, so what happens when data is updated from several directions? (Transactionality is of course also a problem with letting updaters write to both stores...) I'd rather let the RDBMS be the master for most data, and let LDAP worry only about identity, credentials and entitlements, which are rarely changed and only for one set of purposes. For myself, LDAP's ability to deal with hierarchical data isn't all that great a selling point.
Data duplication is not always a bad thing, especially when the usage scenarios are different enough.