3단계 리베이트 프로젝트를 진행하려면 누군가의 1레벨, 2레벨, 3레벨 사용자를 볼 수 있어야 하고 이 사람의 상위 사용자를 변경할 수 있어야 합니다. 데이터 구조는 처음에 설계되었습니다. 예:
uid 1 2 3
사용자 ID는 상사에게 속합니다. 상사에게 속합니다.
1 0 0 0
2 1 0 0
3 2 1 0
4 3 2 1
5 4 3 2
6 3 2 1
사용자 1의 상위는 플랫폼이고 세 가지 상위 레벨은 모두 0입니다. 사용자 6의 상위는 사용자 3, 상위는 2, 상위는 1입니다. 이 구조는 쿼리에 편리하지만 기본 상위를 수정하면 , , 이 사람의 부하 직원이 10만명이라면 이 10만명의 상사도 수정해야 하는데 수정량이 너무 커질 것입니다.
변경된 경우:
uid 1
사용자 ID는 상위에 속함
1 0
2 1
3 2
4 3
5 4
6 3
이 사용자보다 세 번째 하위 사용자를 모두 쿼리하려면 먼저 해당 사용자의 두 번째 레벨 사용자를 모두 쿼리한 다음 모든 두 번째 레벨 사용자의 하위 사용자를 모두 쿼리해야 합니다. 볼륨도 매우 크다.
절충책이 있는지 물어보시겠어요?
3단계 리베이트 프로젝트를 진행하려면 누군가의 1레벨, 2레벨, 3레벨 사용자를 볼 수 있어야 하고 이 사람의 상위 사용자를 변경할 수 있어야 합니다. 데이터 구조는 처음에 설계되었습니다. 예:
uid 1 2 3
사용자 ID는 상사에게 속합니다. 상사에게 속합니다.
1 0 0 0
2 1 0 0
3 2 1 0
4 3 2 1
5 4 3 2
6 3 2 1
사용자 1의 상위는 플랫폼이고 세 가지 상위 레벨은 모두 0입니다. 사용자 6의 상위는 사용자 3, 상위는 2, 상위는 1입니다. 이 구조는 쿼리에 편리하지만 기본 상위를 수정하면 , , 이 사람의 부하 직원이 10만명이라면 이 10만명의 상사도 수정해야 하는데 수정량이 너무 커질 것입니다.
변경된 경우:
uid 1
사용자 ID는 상위에 속함
1 0
2 1
3 2
4 3
5 4
6 3
이 사용자보다 세 번째 하위 사용자를 모두 쿼리하려면 먼저 해당 사용자의 두 번째 레벨 사용자를 모두 쿼리한 다음 모든 두 번째 레벨 사용자의 하위 사용자를 모두 쿼리해야 합니다. 볼륨도 매우 크다.
절충책이 있는지 물어보시겠어요?
mysql 외래 키 재귀
uid와 pid 두 필드만 유지하는 두 번째 솔루션을 채택하는 것이 좋습니다. 이 디자인은 모든 수준의 관계를 지원하며 업데이트가 있는 경우 수정되는 레코드 수가 상대적으로 적습니다.
Oracle의 CONNECT BY 문이나 SQLSQLER의 CTE 등 각 데이터베이스의 재귀 쿼리 구문을 통해 다단계 쿼리를 단순화할 수 있습니다.