2011-01-11 7 views
1

Ich denke über Berechtigungen System für mein Projekt und ich kann keine Entscheidung treffen, wie mein Berechtigungssystem zu organisieren. In kurzen abstrakten Form würde ich meine Frage wie beschreiben:
Sollte ich gemeinsame Entitäten (Zeilen) erstellen und Berechtigungen anwenden oder separate Entity (Zeile) für jeden Benutzer kopieren erstellen?Ist diese Datenbank Design oder Autorisierung/Berechtigungen Zuständigkeit

Meine Situation: Ich habe 2 Einheiten

Company 
{ 
    [PK] 
    Id, 
    Name, 
    Contacts, 
    OwnerUser 
}, 
Contact 
{ 
    [PK] 
    Phone, 
    ContactPerson 
} 

die Beziehung many-to-many haben. Benutzer dürfen die Entität des Unternehmens ändern, die sie selbst erstellt haben.

Mein Problem: Contact-Entity (Zeile) kann zwischen Unternehmen geteilt werden, die verschiedenen Benutzern gehören, und nehmen an, dass beide Benutzer Contact.ContactPerson mit anderem Wert bearbeiten möchten (beispielsweise ein Benutzer behauptet, dass die Telefonnummer John gehört und andere, dass es Toms Nummer ist), kann diese Situation gelöst werden, wenn ich separate Kopie des Kontakts für jedes Unternehmen (und damit Benutzer) erstellen, aber meine Geschäftsregeln erlauben keine doppelten Kontakte mit derselben Telefonnummer und dort andere Kontakteigenschaften das muss (nach meinen Geschäftsregeln) neben der Telefonnummer geteilt werden.

Wie kann diese Situation behoben werden?

Antwort

1

Am Ende müssen Sie eine Richtlinie erstellen. Sie können eine Richtlinie zum Zusammenführen anwenden, wenn ein Konflikt auftrat (wie in der Versionskontrolle), oder eine strikte Richtlinie, dass nur der Ersteller des Kontakts bearbeiten kann, oder jeder kann den Kontakt bearbeiten, solange sich der Kontakt in seiner Firma befindet rating (point) um Zugang zu editieren wie stackoverflow: P.

und diese Probleme können nur gelöst werden mit Fragen direkt an den Kunden, welche eine Richtlinie, die er anwenden möchte.

0

Es klingt wie Ihre Geschäftslogik in Konflikt ist. Auf der einen Seite sagen Sie, dass es für zwei Benutzer möglich ist, sich nicht darüber zu äußern, wer eine Telefonnummer ist (was vollkommen richtig ist, wenn sich zwei Personen einen Schreibtisch teilen). Auf der anderen Seite sagen Sie, dass Ihre Geschäftslogik keine doppelten Telefonnummern zulässt.

Warum besteht Ihre Logik auf eindeutigen Telefonnummern? Es klingt für mich so, als hättest du eine PK erschaffen, die nicht garantiert einzigartig und daher ungeeignet ist.

+0

Das Telefon ist eindeutig und wird geteilt, da es Eigenschaften enthält, die von allen Firmen mit dieser Telefonnummer geteilt werden müssen. Andernfalls müssen wir, wenn sich eine Phone-Eigenschaft ändert (etwa ein Flag), alle Phone-Instanzen in der DB suchen und diese flag \ property aktualisieren. –

+0

In Ordnung; In diesem Fall haben Sie recht, wenn Sie sagen, dass Sie ContactPerson und die Telefonnummer trennen sollten - sie sind separate Entitäten. Ihre Anforderung, dass Kontakte keine doppelten Telefonnummern haben können, ist in diesem Fall jedoch nicht sinnvoll, da dies der Fremdschlüssel ist, der mehrere Kontakte mit einer Telefonnummer verknüpft. – kander