일치하는 SQL 테이블을 구성하거나 결과를 반환하지 마십시오.

Question

흥미로운 디자인 문제가 있습니다. 필자는 프로젝트의 보안 측면을 설계하여 비용이 다른 여러 버전의 프로그램을 보유 할 수있게하고 관리자 유형의 사용자가 프로그램 일부에 대한 액세스를 다른 사용자에게 허용하거나 거부하도록합니다. 웹 기반으로 서버에 호스팅됩니다.

각 '자원'또는 화면에 대해 간단한 허용 또는 거부 옵션을 사용하고 있습니다.

우리는 많은 자원을 가지게 될 것이며 사용자는 사용자를 제어 할 수있는 여러 그룹을 설정할 수 있습니다. 각 사용자는 단일 그룹에만 속할 수 있습니다.

나는이 점을 염두에 두 가지 접근법을 가지고 있으며, 성능면에서 SQL 서버에 더 좋을지 궁금하다.

옵션 A 액세스 테이블에 항목이있는 것은 액세스가 허용됨을 의미합니다. 데이터베이스에 정보를 저장하는 열이 필요하지 않습니다. 결과가 리턴되지 않으면 액세스가 거부됩니다.

나는 이것이 더 작은 테이블을 의미 할 것이라고 생각하지만 쿼리가 전체 테이블을 검색하여 일치하는 것이 없다고 판단 할 것인가?

옵션 B 비트 열은 허용/거부를 ​​제어하는 ​​데이터베이스에 포함됩니다. 이것은 항상 발견 될 결과가 있다는 것을 의미하며 큰 테이블을 만듭니다.

생각하십니까?

Answer 1

허용/거부 만 될 경우 사용자와 리소스 간의 간단한 연결 테이블이 정상적으로 작동합니다. 연결 테이블에서 사용자 자원에 입력 된 항목이 있으면 액세스를 허용하십시오.

UserResources 
------------- 
UserId FK->Users 
ResourceId FK->Resources 

하고 SQL 뭔가 (사용자 ID와의 ResourceId)에 클러스터 된 인덱스와

if exists (select 1 from UserResources 
where UserId = @uid and ResourceId=@rid) 
set @allow=1; 

같은 쿼리도 기록의 수백만 눈부시게 빠른 될 것입니다.

Answer 2

옵션 B에 투표 할 것입니다. 옵션 A를 사용하고 사용자가 존재하면 들어올 수 있다는 가정하에 결국에는 문제가 발생할 수 있습니다. 사용자 레코드를 제거하지 않아도됩니다.

사용자를 잠그고 싶지만 계정을 완전히 파괴하지 않으려는 경우가 많이 있습니다. 그러한 인스턴스 중 하나 (유스 케이스에 연결되어 있지 않아도 됨)는 지불하지 않을 때 발생하며, 다시 지불하기 시작할 때까지 계정을 차단합니다. 계정을 처음부터 다시 만들지 않고 모든 사용자 기록을 잃지 않고 다시 지불 할 때도 사용하도록 설정하기 때문에 레코드를 삭제하고 싶지 않습니다.

Answer 3

B. 데이터가 완료되었는지 (예 : 허용/거부 할 수있는 기능 추가) 훨씬 더 나은 검사가 가능합니다.

또한 테이블 크기는 많은 레코드가 포함될 것으로 예상되는 테이블 (100,000+와 같이)에만 고려해야합니다. 이 질문에 표 크기 고려 사항을 입력하는 데 시간이 걸리는 경우에도 추가 하드 드라이브 공간보다 비용이 많이 듭니다.

Answer 4

접근 방식 A,하지만 암묵적인 deney 외에도 명시 적 거부가 포함됩니다. 귀하의 최종 논리가 작동하는지 확인하기 위해 몇 가지 유스 케이스를 만들지 만 여기에 몇 가지 예가 있습니다.

---

Folder1 allows group1 and deny group2. 
User1 is denied. 
User2 is allowed. 
User3 is denied. 

User1 is in group1 and group2. 
User2 is in group1 
User3 is in group2 

나는 당신의 접근 방식의 사용자 1이 허용 될 것입니다 생각합니다.