具有一些共享数据的多租户数据库

发布于 2024-11-24 06:50:40 字数 726 浏览 0 评论 0原文

我有一个完整的多租户数据库,所有租户数据库上都有 TenantID。这一切都运行良好,只是现在我们需要允许租户数据库“链接到”共享数据。因此,例如,用户可以创建自己的“银行”记录并将帐户链接到它们,但他们也可以将帐户链接到所有租户共享的“全局”银行记录。

我需要一个优雅的解决方案来保持引用完整性

到目前为止我想出的方法:

  1. 复制:所有共享数据都复制到每个租户,可能带有“系统”标志。共享数据的更改涉及所有租户的大量更新。 可能是最简单的解决方案,但我不喜欢数据重复
  2. 特殊 ID:所有共享数据的链接都使用特殊 ID(例如负 ID 号)。这些表明 TenantID 不在关系中使用。 您不能使用 FK 来正确执行此操作,如果您有任何 FK,当然也不能在租户内重复使用 ID。只有触发器可以用于完整性。
  3. 单独的 ID:所有可以链接到共享数据的表都有两个 FK;一种使用 TenantID 并链接到本地​​数据,另一种不使用 TenantID 并链接到共享数据。约束表明要使用其中之一,而不是同时使用两者。 这可能是最“纯粹”的方法,但它看起来......丑陋,但可能不像其他方法那么丑陋。

所以,我的问题分为两部分:

  • 我有什么选择吗?不考虑?
  • 有没有人有过这些选项的经验并对优点/缺点有任何反馈?

I have a full multi-tenant database with TenantID's on all the tenanted databases. This all works well, except now we have a requirement to allow the tenanted databases to "link to" shared data. So, for example, the users can create their own "Bank" records and link accounts to them, but they could ALSO link accounts to "global" Bank records that are shared across all tenants.

I need an elegant solution which keeps referential integrity

The ways I have come up with so far:

  1. Copy: all shared data is copied to each tenant, perhaps with a "System" flag. Changes to shared data involve huge updates across all tenants. Probably the simplest solution, but I don't like the data duplication
  2. Special ID's: all links to shared data use special ID's (e.g. negative ID numbers). These indicate that the TenantID is not to be used in the relation. You can't use an FK to enforce this properly, and certainly cannot reuse ID's within tenants if you have ANY FK. Only triggers could be used for integrity.
  3. Separate ID's: all tables which can link to shared data have TWO FK's; one uses the TenantID and links to local data, the other does not use TenantID and links to shared data. A constraint indicates that one or the other is to be used, not both. This is probably the most "pure" approach, but it just seems...ugly, but maybe not as ugly as the others.

So, my question is in two parts:

  • Are there any options I haven't considered?
  • Has anyone had experience with these options and has any feedback on advantages/disadvantages?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

绾颜 2024-12-01 06:50:42

一位同事给了我一个行之有效的见解。不要将租户访问视为每个租户,而应将其视为组访问。一个租户可以属于多个组,包括它自己指定的组。然后,数据属于一个组,可能是租户的特定组,也可能是更通用的组。

因此,“我的银行”将属于租户组,“本地银行”将属于租户可以访问的区域组,而“全球银行”将属于“每个人”组。

这保持了完整性,FK,并且还增加了拥有租户层次结构的可能性,这在我的场景中根本不需要,但有一个不错的小可能性。

A colleague gave me an insight that worked well. Instead of thinking about the tenant access as per-tenant think about it as group access. A tenant can belong to multiple groups, including it's own specified group. Data then belongs to a group, possibly the Tenant's specific group, or maybe a more general one.

So, "My Bank" would belong to the Tenant's group, "Local Bank" would belong to a regional grouping which the tenant has access to, and "Global Bank" would belong to the "Everyone" group.

This keeps integrity, FK's and also adds in the possibility of having hierarchies of tenants, not something I need at all in my scenario, but a nice little possibility.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文