2010-06-13 7 views
2

객체에 대한 사용자 권한에있어 이상적인 구조는 무엇입니까?MySQL - 객체에 대한 권한을위한 구조

일반 권한 또는 사용자가 액세스 할 수있는 섹션에 대한 많은 관련 게시물을 보았습니다.이 섹션은 users, userGroupsuserGroupRelations 또는 이와 유사한 것으로 구성되어 있습니다.

내 시스템에는 여러 가지 다양한 개체가 생성 될 수 있으며 각 개체는 켜거나 끌 수 있어야합니다. 예를 들어 그룹 및 하위 그룹이있는 암호 관리자를 생각해보십시오.

Group 1 
    Group 2 
    Group 3 
    Group 4 
Group 5 
    Group 6 
Group 7 
    Group 8 
     Group 9 
     Group 10 

각 그룹에는 일련의 암호가 포함될 수 있습니다. 사용자는 모든 그룹에 대해 읽기, 쓰기, 편집 및 삭제 권한을 부여받을 수 있습니다. 어떤 시점에서 더 많은 그룹을 만들 수 있습니다.

그룹에 대한 권한이있는 사용자는 모든 하위 그룹에 권한을 부여하거나 해당 그룹으로만 제한 할 수 있어야합니다.

내 현재의 생각은 다음과 같은 열이있는 권한 표 A 사용자 테이블을 가지고 있으며,이 과거에 근무하고있다,하지만 난 건물에있어 새로운 시스템은 할 수 있어야

permission_id (int) PRIMARY_KEY 
user_id (int) INDEX 
object_id (int) INDEX 
type (varchar) INDEX 
admin (bool) 
read (bool) 
write (bool) 
edit (bool) 
delete (bool) 

규모가 빠르며, 이것이 최고의 구조인지 확신 할 수 없습니다. 또한 그룹의 모든 하위 그룹 권한을 가진 사람을 더 어렵게 만드는 아이디어를 만듭니다.

사용자/관리자 역할에 대한 별도의 테이블이 있습니다. 즉, 제어 할 수있는 그룹 아래의 사용자에 대한 사용 권한을 변경할 수 있습니다.

그럼, 질문으로, 위의 구조를 사용해야합니까? 아니면 누군가가 더 나은 방향으로 나를 가리킬 수 있습니까?


편집

대안은 객체의 모든 유형에 대한 권한 테이블을 만드는 것입니다.

답변

2

"last_update"타임 스탬프와 "last_updated_by_user"열을 추가하여 실행중인 시스템에서이 테이블에 대한 변경 사항을 추적 할 수 있기를 바랍니다.

권한 부여를 추가 할 수 있습니다. 오브젝트에 대한 권한 부여 권한이있는 사용자는 다른 사용자에게 해당 오브젝트에 대한 액세스 권한을 부여 할 수 있습니다.

"빠르게 확장해야합니다." 스케일 업 시스템이 실제로 필요로하는 실제 생산 경험 없이는 추측하기 어렵습니다.

또한 지나치게 복잡한 시스템은 확인하기가 어려우므로 균열이 쉽기 때문에 권한 시스템을 지나치게 복잡하게하지 않도록주의하십시오. 간단한 시스템은보다 복잡한 것보다 스케일 업을 위해 리팩토링하기가 훨씬 쉽습니다.

귀하의 스키마가 사용자를 객체에 연결하는 것처럼 보입니다. 기본 키와 고유 색인을 (user_id, object_id)로 하시겠습니까? 즉, 각 사용자가 각 개체에 대해 0 또는 1 개의 권한 항목을 갖기를 원합니까? 그렇다면 사용자가 제안한 대리 권한 _id 키를 사용하는 대신 기본 키를 사용하여 적용하십시오.

계층에 존재하여 객체의 경우

, 당신이해야 두 가지 선택 중 하나는 시스템 전체 :

  1. 하위 객체 와 객체에 부여 암시에만 개체에 대한 액세스 권한을 부여하거나 ...

  2. 또한 모든 하위 개체에 액세스 권한을 부여합니다.

두 번째 방법은 새 하위 개체를 만들 때 명시 적 사용 권한을 부여하는 부담을 줄입니다. 첫 번째 선택은 더욱 안전합니다.

두 번째 방법을 선택하면 사용자가 액세스 권한이 있는지 확인하는 경우 부모 개체에 대한 액세스 권한 부여를 찾는 트리의 루트를 향해 개체 계층 구조를 이동해야하기 때문에 특정 개체에 대한 액세스 권한이 있는지 여부를 판단하기가 더 어려워집니다 . 그 성능 문제는 의사 결정을 지배해야합니다. 사용자가 몇 개의 개체를 만들어 자주 액세스합니까? 아니면 많은 객체와 하위 객체를 생성하고 거의 액세스하지 않겠습니까? 액세스가 작성보다 자주 발생하면 첫 x 째 선택이 필요합니다. 개체 액세스 시간의 권한 검색 히트가 아니라 개체 생성시 권한 부여 오버 헤드 히트를 가져옵니다.

첫 번째 선택은 아마도 우수하다고 생각합니다.

user_id (int) 
object_id (int) 
type (varchar) (not sure what you have this column for) 
admin (bool) 
read (bool) 
write (bool) 
edit (bool) 
grant (bool) 
delete (bool) 
last_update (timestamp) 
last_updated_by_user_id (int) 
primary key = user_id, object_id. 

당신은이 테이블 레이아웃을 사용하고 각 개체에 대해 각 사용자에게 부여 된 각각의 고유 한 권한 테이블의 행을 가질 수있다 :이 테이블 레이아웃을 제안한다. 이 유형은 더 많은 권한 유형을 추가하면보다 쉽게 ​​확장됩니다.

user_id (int) 
object_id (int) 
permission_enum (admin/read/write/edit/grant/delete) 
type (varchar) (not sure what you have this column for) 
last_update (timestamp) 
last_updated_by_user_id (int) 
primary key = user_id, object_id, permission_enum 
+0

@ Ollie - 정말 고마워요. 'type' 컬럼은 오브젝트 타입을 결정하며, 'object_id'를 별도의 테이블에있는 primary_key와 비교하는데 도움이 될 것입니다. 'admin' 권한 유형은'grant'와 동일합니다. 나는 또한 당신이 동일한 primary_key (정식 교육이 부족하여 여러 개의 컬럼을 만들 수 있음)을 알지 못했지만 훨씬 좋은 생각이라고 생각합니다. 당신이 말한 모든 것은 첫 번째 것이 더 낫다는 것을 암시합니다. ** 나의 유일한 질문은 다음과 같습니다. ** 여러 사용자가 동일한 객체에 액세스 할 수 있습니다. 새 개체가 만들어지면 사용자를 통해 새 권한을 적용해야합니까? –

+1

예, 객체 생성 분야에서는 각 새 객체에 대해 각 사용자에 대한 권한 행을 추가해야합니다. 이와 같은 많은 시스템에는 전역 기본 권한 설정이 있습니다. 예를 들어 권한 테이블에 ID가 표시되지 않은 사용자에게는 읽기 권한이 있지만 그 이외에는 아무 것도 설정하지 않도록 설정할 수 있습니다. Ditto, 객체를 생성하는 사용자는 READ/EDIT/DELETE 그리고 다른 것은 없다. (WRITE 권한과 CREATE SUBOBJECT가 아니라면 아직 권한이 생성되지 않은 개체는 어렵습니다.) –

+0

하하, 예, CREATE 감사합니다. 다시 한 번 감사드립니다. 나는 당신이 더 많은 것을 의미 할 수 있었으면 좋겠다. 이것은 엄청나게 도움이되었다. –