2016-10-13 2 views
2

데이터 모델에 50 개 미만의 엔티티가 있고 보안상의 이유로이 엔티티를 소유 한 사용자를 저장해야한다고 말합니다. 나는 각 요청에 대해 자원에 대해 특정 작업을 수행하는 사용자가 수행 할 수 있는지 (누가 어떤 자원에서 무엇을하고 있는지) 결정할 수 있어야합니다. 그리고이를 위해 자원 소유권이 필요합니다.리소스 소유권을 모델링하는 가장 좋은 방법

나는 이것을 수행하는 몇 가지 다른 방법을 생각할 수 있습니다. 하나는 각 테이블에서 소유자를 가리키는 foreing 키를 가질 수 있다는 것입니다. 이 솔루션의 한 가지 단점은 코드에서 소유권을 찾기 위해 각 개별 테이블을 살펴볼 필요가 있다는 것입니다. 새로운 테이블이 추가 될 때마다 새로운 테이블을보기 위해 코드를 업데이트해야합니다.

또 다른 해결책은 모든 특정 엔터티를 소유권이있는 일반 리소스로 취급 할 수 있습니다. 그리고 그 소유권을 하나의 테이블에 저장하십시오. 외래 키 관계없이 코드를 처리하여 리소스 테이블을 동기화 된 상태로 유지할 수 있습니다. 모든 테이블의 각 u 항목에 "자원"테이블에 해당 레코드가 있는지 확인하십시오. 한 가지 분명한 단점은이 테이블에 많은 레코드가 있다는 것입니다. 이익은 소유권을 찾기 위해 갈 곳이 하나 있다는 것입니다.

그래서 선호되는 방법은 무엇입니까? 결국 거기에 수십만 개의 레코드 (아마도 수백만 개)가있을 수 있으므로 주어진 테이블에 소유권을 저장하는 데 성능 문제가 있습니까? 많은 외래 키 제약 조건을 유지하는 비용은 얼마입니까? 이 문제를 해결하는 더 좋은 방법이 있습니까?

감사합니다.

답변

0

당신은 객체 지향 언어로 작업하고 있습니다. 상속은이 문제를 해결하는 데 완벽합니다.

당신이 코드 첫째, 또는 DB 첫째을 사용하는 경우에 따라, 당신의 접근 방식이 약간 다를 수 있지만,이 귀결 :

  1. 하고 추상 클래스, 당신은 'OwnableEntity'와 같은 이름을 호출 할 수 있습니다. 본질적으로, 외래 키와 네비게이션 속성을 거기에 넣습니다.
  2. 은 모든 엔티티를 상속이 'OwnableEntity'
  3. 이제부터

을 EF에서 상속 매핑이 올바른지 확인 (이 경우, TPC inheritance 매핑 당신은 아마 사용하기를 원할 것입니다 무엇을) 확인 'OwnableEntity'에 대한 '소유권 확인'논리를 작성할 수 있으며, 나중에 구현하는 모든 엔티티에서 정상이됩니다.

+0

좋은 소리입니다. TPC를 올바르게 이해한다면 (소유권 클래스가 추상적이라고 가정 할 때) 각각의 구체적인 유형 테이블이 다른 모든 구체적인 클래스에서 동일한 두 개의 컬럼을 유지하게됩니다. 소유자 및 OwnableEntity-key 열에 대한 참조 하나. 따라서 소유권 세부 정보는 별도의 테이블에 저장되지 않고 각 하위 유형 테이블에 분산됩니다. 서로 다른 테이블에있는 두 개의 구체적인 유형 레코드가 동일한 OwnableEntity-key를 공유하지 않는다고 어떻게 여깁니까? – user1467609

관련 문제