对用户进行分区 - 多个 OpenID

发布于 2024-09-24 11:58:25 字数 553 浏览 2 评论 0原文

有用户数据库。
假设我想支持某些用户可以拥有多个 OpenID 并使用它们登录,假设我想将用户分区到多个数据库中。

有什么解决办法吗? StackOverflow 支持每个用户两个 OpenID,他们会如何做到这一点?

如果用户只能使用一个OpenID,那么分区就有多种选择。对于多个 OpenID,我有两个具有 1-n 关系的表。

在这种情况下是否有某种算法可以进行有效的分区?

更新 正如 Noon Silk 提到的,该问题并非 OpenID 特有。我只是对分区感兴趣,我提到 OpenID 是因为它在这种情况下可能与创建映射函数相关。

尝试将其视为一个普遍问题。
我有两个表 A 和 B,关系 n 为 1。是否有一些规则/建议如何在这种情况下进行分区,以便完整的信息位于一个数据库中?

如果
A1 与 B1 相关
A2 与 B1 相关
A3 与 B1 相关

A4 与 B2 相关
A5与B2相关

如何将A1-A3和B1放在一个数据库中,将A4-A5和B2放在另一个数据库中?

There is database of users.
Let's say that I want to support that some users can have multiple OpenID's and use them to log in and let's say that I want to partition Users in to the multiple databases.

Is there some solution for this ? StackOverflow supports two OpenIDs per user, how would they do this?

If the users could use only one OpenID, there would be multiple choices for partitioning. With multiple OpenIDs I have two tables with 1-n relation.

Is there some algorithm to do efficient Partitioning in this case?

Update
As Noon Silk mentioned, the problem is not specific to OpenID. I am just interested in partitioning and I am mentioning OpenID because it may be relevant in this case for creating mapping function.

To try to put it as a generic problem.
I have two tables A and B with relation n to 1. Are there some rules/recommendations how to do partitioning in this case so that complete information is in one database ?

if
A1 is related to B1
A2 is related to B1
A3 is related to B1

A4 is related to B2
A5 is related to B2

how to put A1-A3 and B1 in one database and A4-A5 and B2 in another database ?

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

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

发布评论

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

评论(3

独夜无伴 2024-10-01 11:58:25

如果您将其放入 Azure 表 (AZT) 中,我实际上会使用两个表。由于您希望在用户登录时通过 OpenId 查找用户,因此我将有一个 UserOpenId 表,其中分区键是他们的整个 OpenId,行键为空白或其他常量,并且它具有您的实际用户 ID在另一个领域。然后将用户 ID 作为主用户表中的分区键(同样使用行键常量)。这将为您提供查找该用户的最快方法。确保您的查询中同时包含 PartitionKey 和 RowKey。

使用 AZT,您无需担心分区大小是否均匀,只需担心如何从中获取数据。如果您一次只取出一项特定项目,请将分区键设为您要用来查找该项目的项目。如果您要按组取出项目,请使用您要查找的分区键和唯一 ID 的行键。

If you're putting this in an Azure tables (AZT), I would actually use two tables. As you're going to want to look up users by OpenId when they're logging in I would have an UserOpenId table where the partition key is their whole OpenId, the row key is blank or some other constant and it has your actual user ID in another field. Then have the user ID as the partition key in your main user table (again with a constant for the row key). This will give you the fastest way of looking up that user. Make sure you include both the PartitionKey and the RowKey in your query.

With AZT you don't need to worry about your partitions being evenly sized, you just need to worry about how you're going to get data out of them. If you're only ever getting out one specific item at a time, make the partition key the item you're going to look it up by. If you're going to get the items out in groups, use the partition key the thing you're going to be looking it up by and the row key the unique id.

凡尘雨 2024-10-01 11:58:25

OpenID 实际上只是用户的唯一 ID。因此,显然,您可以为每个“用户”关联多个这些。

因此,如果您希望有多种(由于某种原因 n 增加)方法将系统中的用户与 OpenID 链接起来,显然链接表是有意义的(即 tblUser -> tblUserOpenIDs,或类似的方法)。

An OpenID is effectively just an Unique ID for a user. So, obviously, you can associate more than one of these per "User".

So, if you want to have multiple (with n increasing for some reason) ways to link a user in your system with an OpenID, clearly a linking table makes sense (i.e. tblUser -> tblUserOpenIDs, or similar approach).

你怎么这么可爱啊 2024-10-01 11:58:25

“如何将A1-A3和B1放入一个数据库,将A4-A5和B2放入另一个数据库?”

在现实生活中实现这一点的一种方法是放弃自动引用完整性检查,并将两个表视为两个完全独立的实体。这样你就可以像Noon Silk建议的那样进行分区。两者不需要位于同一个数据库中(不过这会很好),特别是因为两个表都是相当不可变的。

"how to put A1-A3 and B1 in one database and A4-A5 and B2 in another database ?"

One approach to make this work in real life is to give up on automatic referential integrity checks and treat both tables as two completely independent entities. This way you can partition like Noon Silk suggested. There is no need for both to be in the same database (it would be nice though), especially as both tables are rather immutable.

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