Partitionnement des utilisateurs - plusieurs OpenID

Question

Il existe une base de données des utilisateurs. Supposons que je veux prendre en charge que certains utilisateurs peuvent avoir plusieurs OpenID et les utiliser pour se connecter et disons que je veux partitionner les utilisateurs dans les bases de données multiples.

Y at-il une solution pour cela? StackOverflow prend en charge deux OpenID par utilisateur, comment feraient-ils cela?

Si les utilisateurs ne pouvaient utiliser qu'un seul OpenID, il y aurait plusieurs choix pour le partitionnement. Avec plusieurs OpenID, j'ai deux tables avec une relation 1-n.

Existe-t-il un algorithme pour effectuer un partitionnement efficace dans ce cas?

Mise à jour Comme l'a mentionné Noon Silk, le problème n'est pas spécifique à OpenID. Je suis juste intéressé par le partitionnement et je mentionne OpenID car il peut être pertinent dans ce cas de créer une fonction de mapping.

Pour essayer de le mettre comme un problème générique.
J'ai deux tables A et B avec la relation n à 1. Existe-t-il des règles/recommandations sur la façon de faire du partitionnement dans ce cas afin que l'information complète soit dans une base de données?

si
A1 est lié à B1
A2 est en relation avec B1
A3 est liée à B1

A4 est lié à B2
A5 est lié à B2

comment mettre A1 -A3 et B1 dans une base de données et A4-A5 et B2 dans une autre base de données?

Answer 1

Un OpenID est effectivement juste un ID unique pour un utilisateur. Donc, évidemment, vous pouvez en associer plus d'un par "Utilisateur". Donc, si vous voulez avoir plusieurs manières (avec n augmentant pour une raison quelconque) de lier un utilisateur dans votre système avec un OpenID, il est clair qu'une table de liaison est logique (par exemple tblUser -> tblUserOpenIDs, ou approche similaire).

Answer 2

Si vous mettez ceci dans des tables Azure (AZT), j'utiliserais deux tables. Comme vous allez vouloir rechercher des utilisateurs par OpenId quand ils se connectent, j'aurais une table UserOpenId où la clé de partition est leur OpenId entière, la clé de ligne est vide ou une autre constante et elle a votre ID utilisateur réel dans un autre domaine. Ayez ensuite l'ID utilisateur comme clé de partition dans votre table utilisateur principale (toujours avec une constante pour la clé de ligne). Cela vous donnera le moyen le plus rapide de rechercher cet utilisateur. Assurez-vous d'inclure à la fois le PartitionKey et le RowKey dans votre requête.

Avec AZT, vous n'avez pas besoin de vous soucier de la taille de vos partitions, il vous suffit de vous soucier de la façon dont vous allez en extraire les données. Si vous ne sortez qu'un seul élément à la fois, faites de la clé de partition l'élément que vous rechercherez. Si vous voulez sortir les objets dans des groupes, utilisez la clé de partition la chose que vous allez rechercher et la clé de la ligne l'identifiant unique.

Answer 3

"comment mettre A1-A3 et B1 dans une base de données et A4-A5 et B2 dans une autre base de données?" Une approche pour que cela fonctionne dans la vie réelle consiste à abandonner les contrôles d'intégrité référentielle automatiques et à traiter les deux tables comme deux entités complètement indépendantes.De cette façon, vous pouvez partitionner comme Noon Silk suggéré. Il n'est pas nécessaire que les deux soient dans la même base de données (ce serait bien quand même), d'autant plus que les deux tables sont plutôt immuables.