Partitioning the Users - multiple OpenIDs

Question

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 ?

Answer 1

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).

Answer 2

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.

Answer 3

"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.