2011-01-10 6 views
1

Ich habe folgende Aufgabe. Mit drei Modellen Project, User und PurchaseOrder. Ich möchte eine Mitgliedschaft für einen Benutzer in einem Projekt erstellen können. Ein Benutzer kann Mitglied in beliebigen Projekten sein. Dies kann mit einem ManyToManyField gelöst werden.Viele-zu-viele-Beziehung mit zusätzlichen Feldern - wie man Eindeutigkeit umgehen kann

Zusätzlich sollte sich eine Mitgliedschaft auf einen PurchaseOrder beziehen, da ich die Arbeitsstunden bestimmten PurchaseOrders zuordnen möchte.

Ich denke, dass dies gelöst werden könnte, indem Sie ein through-table für das ManyToManyField verwenden und ein ForeignKey für das PurchaseOrder-Modell definieren. Somit hätte ich für jede Mitgliedschaft einen Hinweis auf eine Kauforder.

In Wirklichkeit wird eine Mitgliedschaft für ein Projekt aktiv bleiben, während, nachdem das Geld für einen PurchaseOrder ausgegeben wurde, ein neuer PurchaseOrder der Mitgliedschaft zugewiesen werden muss. Dies wäre auch einfach, indem Sie den ForeignKey einfach auf einen neuen PurchaseOrder aktualisieren.

Aber jetzt meine Frage:

ich das alte Projekt-Mitgliedschaft-PurchaseOrder-Relation (Datenzeile in der Mitgliedertabelle, für die Geschichte Tracking) behalten möchten, setzen Sie ihn auf Behinderte und fügen Sie eine neue Projekt-Mitgliedschaft -PurchaseOrder-Relation, die denselben ForeignKey wie Benutzer und Projekt, aber einen anderen als den PurchaseOrder hat, und ein Flag, das auf aktiviert gesetzt ist.

Ist dies ein gültiger Ansatz, wird das funktionieren, wird es möglich sein, die Eindeutigkeit zu umgehen (oder gibt es keine Definition für das ManyToManyField per Definition), oder haben Sie eine bessere Idee, wie das geht?

+0

Ich bekomme nicht wirklich den Punkt, wenn Sie wollen, dass Mitgliedsobjekte "einzigartig" sind? –

+0

Ich möchte nicht, dass Mitgliederobjekte einzigartig sind, ich dachte, sie könnten einzigartig sein. Aber ich habe es einfach überprüft und sie sind es auch nicht. Was gut ist. Ich hätte es wahrscheinlich überprüfen sollen, bevor ich die Frage gestellt habe. –

Antwort

1

Wenn ich das durchlese, kann ich nicht herausfinden, warum man sich sogar mit der Many-to-Many-Beziehung für den Member> PurchaseOrder beschäftigt.

Ich würde es eine One-to-Many-Beziehung für Member> PurchaseOrder und ein Viele-zu-Viele-Relation Member> Project machen, da die Mitgliedschaft der Primärschlüssel für alles zu sein scheint.

Auf diese Weise müssen Sie keine Schlüssel aktualisieren. Dann würde ich ein viertes Modell erstellen, das eine Many-to-Many-Beziehung hat, die die Einkäufe verfolgt. Hinzufügen der Mitgliedschaft prim. Schlüssel und der PurchaseOrder prim.key.

+0

Wenn Sie über Mitglied sprechen, meinen Sie User !? –

+0

Sie haben Recht. Das hat mich in die richtige Richtung gelenkt. Vielen Dank. –

Verwandte Themen