2012-12-01 2 views
2

우리는 각각 다른 속성을 가진 약 5 개의 사용자 역할을 가진 웹 사이트에서 작업하고 있습니다. 데이터베이스 스키마의 현재 버전에서는 모든 사용자와 모든 속성을 보유하는 단일 사용자 테이블이 있습니다.서로 다른 역할을 가진 사용자를위한 최적의 테이블 구조

우리가 필요로하는 속성은 사용자 역할마다 다릅니다. 모든 사용자는 이름, 전자 메일 주소 및 암호와 같은 기본 속성을가집니다. 하지만 그 역할에 따라 속성이 다릅니다. 일부에는 소셜 미디어 링크가 있고 다른 사람에게는 인보이스 주소가 있습니다. 총 60 개의 열 (속성)이있을 수 있으며 그 중 일부만 각 사용자 역할에 사용됩니다.

전체적으로 우리는 테이블에 약 250,000 명의 사용자가있을 수 있습니다. 그 중 가장 큰 부분 (약 220,000)은 단일 사용자 역할이고 60 개 열 중 약 20 개가 사용됩니다. 다른 30,000 명의 사용자는 4 개의 다른 규칙으로 나누어지고 나머지 40 개의 열의 하위 집합을 사용합니다.

DB의 개발 관점에서 가장 좋은 데이터베이스 구조는 무엇입니까? 내 생각은 명의 사용자가 테이블 인 다음 명의 사용자가 _ 개의 중재자 인과 같은 테이블로 확장하는 것이지만 JOIN의 많은 쿼리가 생성 될 수 있습니다. 이 문제를 방지하는 방법은 VIEW를 사용하는 것입니다 만,보기가 성능을 해칠 수있는 몇 가지 (기한이 지난) 기사를 읽었습니다 (예 : http://www.mysqlperformanceblog.com/2007/08/12/mysql-view-as-performance-troublemaker/).

'완벽한'구조가 존재합니까? 어떤 제안이나 전혀 문제가되지 않으며 모든 사용자를 하나의 큰 테이블에 배치해야합니까?

답변

0

여기서는 속도를 너무 걱정할 필요가 없다고 생각합니다. 일회성 일 뿐이니까. 즉 사용자 로그인에서 세션의 acl을 저장하고 거기에서 다음 번에 가져옵니다.

JOIN은 그렇게 나쁘지 않습니다. InnoDB 엔진으로 올바른 위치에 인덱스와 외래 키를 가지고 있으면 정말 빠를 것입니다.

사용자 및 role_id에 대해 하나의 테이블을 사용합니다. 역할이있는 두 번째 테이블. 세 번째 테이블은 리소스를위한 것이고 하나는 모두 함께 링크 + 활성화 된 플래그입니다.

+0

답장을 보내 주셔서 감사합니다. 따라서 사용자 220,000 명에 대해 40 개의 열이 비어 있다는 사실과 상관없이 모든 사용자를 단일 테이블로 유지할 것을 권장합니다. –

+0

220,000 행이 아무 것도 없음에 동의합니다. 40 열이 나쁜 엔지니어링이라는 데 동의합니다. EAV 모델을 사용하여 관련 사용자 데이터를 저장할 수 있습니다. 나는 테이블 아이디어에 대한 모든 사용자 그룹 데이터를 정말로 좋아하지 않는다. – wormhit

+0

제안 해 주셔서 감사합니다. EAV는 여기 저기에있을 수있는 가능성이 있지만 여기 저기에있을 수도 있습니다. 60 개 자산에 대해 과도 할 수는 있지만 옵션으로 간주 할 것입니다. –

1

이러한 경우에 대한 '완벽한'구조는 제 생각에는 당 - 역할 관계 모델입니다. 데이터 모델에 대한 Len Silverston의 책을 검색하십시오. 처음에는 매우 복잡해 보이지만 큰 유연성을 제공합니다 ...

가장 큰 질문은 완벽한 솔루션을 채택하는 실용성입니다. 당신을 제외하고 아무도 그 대답을 할 수 없습니다. 리팩토링은 쉽고 빠른 작업이 아니므로 프로젝트 수명이 1 년이라면 '기술 부채'를 지불하는 데 9 개월을 소비하는 것이 시간/노력의 낭비와 비슷합니다.

조인의 성능에 대해서는 적절한 인덱스가 있으면 일반적으로 잠재적 인 문제가 해결됩니다. 그렇지 않은 경우 항상 구체화 된보기를 구현할 수 있습니다. mysql에 초기부터 그런 옵션이 없다고해도, 직접 디자인하고 다른 방법으로 새로 고침 할 수있다. (예를 들어, 트리거를 사용하거나 필요에 따라 정기적으로 새로 고침 절차를 시작한다.)

+0

답장을 보내 주셔서 감사합니다. party-role-relationship을 올바르게 적용하라는 제안을 이해한다면, 사용자에게 최소한의 컬럼 만 넣고 다른 테이블 (파티 관계)에서 그 테이블을 확장해야합니다. –

+0

@vvanscherpenseel : 네, 이상적으로 사용자 테이블은 특정 역할의 구성원으로서 사용자와 관련된 정보가 다른 열 [s]에 저장되는 열이 거의 없습니다. 또한 일부 데이터는 특정 관계 내에서만 실제로 의미가 있으므로 user_role 또는 relationship ... – a1ex07

+0

올바른 정보를 파악하는 것이 약간 까다로울 수 있습니다. 확실히 고려해야 할 좋은 옵션입니다. –

1

두 가지 다른 방법이 있습니다. 하나는 "단일 테이블 상속"이라고합니다. 기본적으로 의견을 물어 보는 디자인입니다. 조인이 없기 때문에 꽤 빠릅니다. 그러나 뚱뚱한 행이 더 얇은 행보다 메모리에 가져 오기 위해 약간 더 오래 걸리므로 NULL은 처리량에 약간의 영향을 줄 수 있습니다.

다른 디자인을 "클래스 테이블 상속"이라고합니다.이 디자인에서는 수퍼 클래스에 대해 하나의 테이블이 있고 각 서브 클래스에 대해 하나의 테이블이 있습니다. 키가 아닌 속성은 테이블과 관련됩니다. 종종 "공유 기본 키"라는 디자인을이 디자인과 함께 사용할 수 있습니다. 공유 기본 키에서 하위 클래스 테이블의 키 ID는 수퍼 클래스 테이블의 해당 행에있는 ID의 복사본입니다.

삽입 시간에는 약간의 효과가 있지만 데이터를 결합 할 때 비용은 그다지 지불하지 않습니다.

SO에서 태그를 가지고 있거나 웹에서 태그를 찾아야합니다. 디자인에 대한 자세한 내용과 각 디자인이 자신의 케이스에 얼마나 잘 맞는지 나타낼 수 있습니다.

1

table user table roles table permissions table userRole table userPermission table RolesPermissions

각 역할이있다는

그래서 PHP에서 방금 사용자 권한의 배열을 병합해야합니다 (... 확장자) 역할 권한의 권한 테이블 각 사용자가 권한 whitout 역할을 할 수있다 사용자 역할 및 확장 된 권한에서 ... 그리고 "acl"클래스에서 사용자가 웹 페이지 또는 시스템 프로세스를 보거나 처리 할 수있는 권한이 있는지 확인하십시오.

+0

답장을 보내 주셔서 감사합니다. 하지만 제 질문은 ACL 부분이 아니라 역할 종속 속성의 저장에 관한 것입니다. –

관련 문제