2011-01-10 2 views
1

다음 작업을 수행합니다. Project, User 및 PurchaseOrder의 세 가지 모델이 있습니다. 나는 프로젝트에서 사용자를위한 멤버쉽을 만들 수 있기를 원한다. 사용자는 임의 프로젝트의 회원이 될 수 있습니다. 이 문제는 ManyToManyField를 사용하여 해결할 수 있습니다.추가 필드와 다 대다 관계 - 고유성을 우회하는 방법

또한 특정 PurchaseOrders에 근무 시간을 할당하고자하므로 멤버쉽은 PurchaseOrder를 참조해야합니다.

이 문제는 ManyToManyField에 through-table을 사용하고 PurchaseOrder 모델에 ForeignKey를 정의하여 해결할 수 있다고 생각합니다. 따라서 각 멤버쉽에 대해 PurchaseOrder에 대한 참조가 있어야합니다.

실제로 프로젝트의 회원 자격은 계속 유지되는 반면, PurchaseOrder에 돈을 지출 한 후에는 새 PurchaseOrder를 회원 자격에 할당해야합니다. 또한 ForeignKey를 새 PurchaseOrder로 업데이트하면 쉽게 수행 할 수 있습니다.

하지만 지금은 내 질문 : 나는 (이력 추적을위한 회원 테이블의 데이터 행) 이전 프로젝트 - 회원 - PurchaseOrder에-관계를 유지하려는

는 비활성화로 설정하고 새로운 프로젝트 - 회원 추가 -PurchaseOrder-Relation은 사용자 및 프로젝트에 대해 동일한 외래 키를 갖지만 PurchaseOrder와는 다르고 사용 가능으로 설정된 플래그입니다.

이 방법이 유용할까요?이 방법을 사용하면 고유성을 우회하는 것이 가능합니다 (또는 ManyToManyField의 고유성이 없음). 또는이를 수행하는 방법을 더 잘 알고 있습니까?

+0

멤버십 개체를 "고유"로 설정하려면 정말로 요점을 얻지 못합니까? –

+0

회원 개체가 고유하지 않기를 바랄뿐입니다. 고유하다고 생각했습니다. 하지만 방금 확인했는데 그렇지 않았습니다. 어느 것이 좋니. 내가 질문을하기 전에 확인 했어야했는데. –

답변

1

이 글을 읽으면 멤버> PurchaseOrder에 대한 다 대다 관계가 왜 어려워하는지 알 수 없습니다.

Member> PurchaseOrder 및 Many-to-Many 관계 멤버> 프로젝트에 대해 일대 다 관계로 만들 것입니다. 멤버쉽이 모든 멤버의 기본 키인 것처럼 보입니다.

이렇게하면 키를 업데이트하지 않아도됩니다. 그런 다음, 구매를 추적하는 다 대다 관계를 갖는 네 번째 모델을 작성합니다. Membership prim 추가하기. key 및 PurchaseOrder prim.key를 사용하십시오.

+0

회원에 대해 이야기하는 경우 사용자를 의미합니다!? –

+0

당신 말이 맞아요. 그것은 올바른 방향으로 나를 가리켰다. 감사. –