강사 및 고객 데이터베이스를위한 최고의 디자인을 생각하려고합니다. 클라이언트와 트레이너의 일반적인 속성엔티티 관계 - DB 디자인
법인 person (이름, 생년월일 등) :
내 최초의 생각이 있었다. 클라이언트는 한 명의 트레이너 만 가질 수 있습니다. 한 트레이너는 많은 고객을 가질 수 있습니다.
궁금 클라이언트와 트레이너 권한을 제어하거나 person
내가 재귀 관계를 하나의 개체에서 모든 것을 가졌다 고려했던 또 하나의 속성 Role을 추가 엔티티 user를 작성 여부 ?
의견이 있으십니까?
감사합니다.
엔티티의 관점에서 트레이너와 클라이언트는 아마도 각각에 대해 추적 할 다른 데이터를 가지고있을 것입니다. 여전히 전역 사용자 테이블을 가질 수 있지만 트레이너와 클라이언트는 사용자 엔터티와 1 : 1 관계를 가져야합니다. 그런 다음 클라이언트와 트레이너간에 조인 테이블을 가질 수 있습니다. 나는 여기에 많은 관계를 제안 할 것입니다, 누군가가 정말로 모양에 들어가기를 원하고 2 명의 강사를 원할 때를 대비하여.
그 테이블을 글로벌 테이블로 매핑하겠습니까? '사용자'와 클라이언트 및 트레이너의 속성과 역할을 가진 두 번째 테이블을 가정 해 봅시다. 감사. – Paragon
당신이 원하는 구체적인 방법에 달려 있습니다. 추적하려는 데이터가 핵심 사용자 데이터를 훨씬 넘어서는 경우 두 개의 다른 테이블을 권장합니다. 누군가 트레이너와 클라이언트 모두 일지라도 트레이너 엔티티는 특정 데이터를 트레이닝해야하므로 클라이언트는 중복성이 없지만 클라이언트는 클라이언트 별 데이터이며 모든 글로벌 데이터는 사용자 테이블에 표시됩니다. – Nick
고맙습니다. 닉. 나중에 필요한 경우 더 구체적인 데이터를 추가 할 수 있도록 두 개의 다른 테이블로 이동했습니다. 그리고 클라이언트와 트레이너 간의 조인 테이블을 사용하여 클라이언트가 새 트레이너와 함께 트레이닝을 시작한 날짜를 유지합니다. – Paragon
트레이너가 트레이너를 가질 수 있습니까? 예를 들어, 트라이 애슬론을 전문으로하는 트레이너는 약한 수영 선수 일 수도 있고 수영 코치가있을 수도 있습니다.
나는 Role 자신을 디자인했습니다. (아이디, 이름, 생년월일이, 사용자 이름, 암호, ... 너무 여기에 주소를 유지합니다) UserRole (사용자 아이디, 역할 ID) 역할 사용자 :
는 귀하의 의견에 대한 여러분 모두 감사합니다, 이것이 내가 생각 해낸 것입니다 (역할 ID, 역할) RolePermission (역할 ID, PermissionId) 권한 (PermissionId, 권한) 클라이언트 (클라이언트 ID, 사용자 아이디, NextOfKin, ...) 트레이너 (TrainerId, 사용자 아이디, 레벨, ...) ClientTrainer (clientid는, TrainerId) 계속하기 전에 귀하의 의견을 듣고 싶습니다. 감사. – Paragon