Un-à-plusieurs ou plusieurs-à-plusieurs?

Ceci est la question BestPractice (ou du moins j'espère que c'est).Un-à-plusieurs ou plusieurs-à-plusieurs?

EDIT: Cet exemple est juste pour clarifier le problème. Ce pourrait être la personne, le bureau, l'information de contact.

Le problème:

Il y a 3 tables:

RightsSet 
(
    ID, 
    CanView, 
    CanEdit, 
    ObjectTypeID, 
    ObjectID 
) 

User 
(
    ID, 
    Username, 
    Password, 
    ProfileID 
) 

ProfileID 
(
    ID, 
    Name, 
    Description 
)

l'utilisateur et le profil peuvent avoir plusieurs RightsSets. RightsSet doit appartenir à 1 (et seulement 1) utilisateur ou profil.

Comment y parvenir? Dois-je créer des tables supplémentaires

UserRightsSets 
(
    UserID, 
    RightsSetID 
) 

ProfileRightsSets 
(
    ProfileID, 
    RightsSetID 
)

Le problème est: Comment assurez-vous que lorsque ProfileRightsSet est supprimé, le RightsSet est également supprimé (parce que RightsSet appartient au profil et au profil seul)? Comment s'assurer que RightsSet n'appartient qu'au profil et non au profil et à l'utilisateur?

Sinon, je pourrais modifier la table RightsSet

RightsSet 
(
    ID, 
    CanView, 
    CanEdit, 
    ObjectTypeID, 
    ObjectID, 
    UserID, 
    ProfileID 
)

Le problème avec ce ... Eh bien, si plusieurs objets partagent RightsSet? (Ok, je ne peux pas penser à un exemple, mais je suis sûr qu'il ya des scénarios valides où plus de 2 types d'actions de l'entité une sorte d'entité.)

Source

2011-10-11 Andrija Frlan

Le tout semble plutôt mal pensé - pourquoi ne pas faire ce que font la plupart des systèmes d'autorisation et utiliser des rôles qui peuvent être assignés à un nombre quelconque d'utilisateurs? –

Eh bien ... Il n'est vraiment pas question d'utilisateurs et de profils ... Il s'agit de relation entre 3 entités dans lesquelles 2 entité peut avoir plusieurs de 3ème, mais 3ème doit appartenir à précisément 1. –

C'était une question difficile pour moi d'envelopper ma tête autour, mais vous pouvez envisager la structure ci-dessous:

Entity 
--------- 
EntityId 
ProfileId --nullable 
UserId --nullable 

RightsSet 
---------- 
EntityId 
CanView 
CanEdit 
ObjectTypeID 
ObjectID

Avec cette méthode, vous pouvez spécifier une contrainte UNIQUE sur ProfileId et UserId dans le tableau Entity puis créer autant d'enregistrements en RightsSet que nécessaire. Deux problèmes possibles seraient lorsque ProfileId et UserId dans Entity sont tous les deux nuls ou quand ils ont tous les deux des valeurs. Vous pouvez probablement effectuer une validation avant d'insérer des enregistrements pour vous assurer que cela ne se produit pas.

Source

2011-10-11 23:01:17

Si j'ajoutais Unique sur ProfileId et UserId, est-ce que cela éliminerait la possibillité de l'utilisateur ayant plusieurs RightsSets? –

@Andrija: Non, vous pourriez avoir beaucoup de RightsSets qui ont la même 'EntityId' donc appartenir au même profil ou utilisateur. –

Bien sûr. PK pour RightsSet est déplacé vers l'entité. Cela, en fait, a beaucoup de sens. Que toi! –

Ajouter un supertype Entity table qui a des sous-types User et Profile (1:1 relation avec les deux).

Ensuite, laissez Entity et RightsSet être dans 1:n relation.

Source

2011-10-11 22:54:37

+1, je suis descendu par le même chemin (Entité même utilisée). –

J'ai accepté l'autre réponse parce qu'elle est clearee. Même s'ils sont, essentiellement, les mêmes. En tout cas, merci! –

Merci. Notez qu'ils ne sont pas des réponses identiques, seulement similaires. Il n'y aura pas de valeurs NULL dans le mien. Et les JOINs seront différents dans les 2 versions, pas sûr de ce qui sera le plus clair. –

Un-à-plusieurs ou plusieurs-à-plusieurs?

Répondre

Questions connexes