5개의 표는 여기에서 참고하실 수 있습니다: http://www.lyblog.net/detail/...
실제로 테이블이 있습니다:
사용자와 역할 사이에는 일대일 대응이 있습니다. 다른 테이블을 생성하는 대신 사용자 테이블에 역할 필드를 추가하는 것은 어떨까요?
이렇게 하면 어떤 이점이 있나요?
보충:
어떤 사람들은 사용자와 역할이 일대다 관계라고 하는데 왜 일대다로 설정해야 하는지 알고 싶습니다.
일대일 관계를 다루는 것이 더 쉽지 않나요?
5개의 표는 여기에서 참고하실 수 있습니다: http://www.lyblog.net/detail/...
실제로 테이블이 있습니다:
사용자와 역할 사이에는 일대일 대응이 있습니다. 다른 테이블을 생성하는 대신 사용자 테이블에 역할 필드를 추가하는 것은 어떨까요?
이렇게 하면 어떤 이점이 있나요?
보충:
어떤 사람들은 사용자와 역할이 일대다 관계라고 하는데 왜 일대다로 설정해야 하는지 알고 싶습니다.
일대일 관계를 다루는 것이 더 쉽지 않나요?
사용자가 여러 역할을 가질 수 있다고 알고 있습니다
이렇습니다.
한 사람이 여러 역할을 가질 수 있습니다
한 역할은 여러 사람이 사용할 수도 있습니다
다대다 관계에서는 일반적으로 매핑할 중간 테이블이 필요합니다.
redis 비관계형 데이터베이스를 사용하지 않는 경우
일대다가 아니라 다대다입니다.
프로젝트에 필요하지 않을 수도 있지만 프레임워크로서 더 넓은 요구 사항을 고려해야 합니다. 이러한 관점에서 다대다 테이블은 일대일 테이블로 사용될 수 있습니다. 많은 것에는 일대일이 포함됩니다. 그러나 일대일 디자인은 필연적으로 다대다의 요구를 충족하지 못합니다. 그러면 여기에는 별도의 관계 테이블이 있을 것입니다. 알죠?
사용자에게는 여러 역할이 있습니다.
사실 별도의 테이블을 만들지 않는 것도 가능합니다.
분리, 단일 책임 모델
ManytoMany 관계에는 중간 테이블이 필요합니다!
다대다 요구를 충족하기 위해
제가 이해한 것이 정확하지 않을 수 있습니다. 예를 들어, 사용자 1, 2, 3은 여러 역할 a, b, c가 있습니다. 각각 a와 b에 해당합니다. ,c 세 가지 역할은 문제가 되지 않습니다. 다른 사용자 4가 오면 그에게 필요한 역할은 우연히 역할 a와 b의 권한을 갖게 되므로 사용자 4는 직접 역할 a와 b에 속합니다. 사용자 4의 요구 사항을 충족하기 위해 새 역할 d를 만들 필요가 없습니다