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 の上司はプラットフォームで、3 つの上司レベルはすべて 0 です。ユーザー 6 の上司はユーザー 3、その上司は 2、その上司は 1 です。この構造はクエリに便利ですが、デフォルトの上司を変更すると、この人の部下は10万人おり、その10万人の上司も修正する必要があり、修正量が多すぎます。
次のように変更された場合:
uid 1
ユーザー ID は上位に属します
1 0
2 1
3 2
4 3
5 4
6 3
このユーザーから 3 番目のレベルのすべてのユーザーをクエリするには、次の操作が必要です最初にユーザーをすべての第 2 レベルのユーザーにクエリし、次にすべての第 2 レベルのユーザーのすべての部下をクエリすると、クエリの量も非常に多くなります。
妥協案があればお聞きしたいのですが？

返信内容:

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 の上司はプラットフォームで、3 つの上司レベルはすべて 0 です。ユーザー 6 の上司はユーザー 3、その上司は 2、その上司は 1 です。この構造はクエリに便利ですが、デフォルトの上司を変更すると、この人の部下は10万人おり、その10万人の上司も修正する必要があり、修正量が多すぎます。
次のように変更した場合:
uid 1
ユーザー ID は上位に属します
1 0
2 1
3 2
4 3
5 4
6 3
次に、下から 3 番目のレベルでこのユーザーのすべてのユーザーをクエリします、最初にユーザーをすべての第 2 レベルのユーザーにクエリし、次にすべての第 2 レベルのユーザーのすべての部下をクエリする必要があるため、クエリの量も非常に大きくなります。
妥協案があればお聞きしたいのですが？

mysql外部キー+再帰

uid フィールドと pid フィールドのみを保持する 2 番目のソリューションを採用することをお勧めします。この設計では、あらゆるレベルの関係がサポートされ、更新があった場合でも、変更されるレコードの数は比較的少なくなります。
マルチレベルクエリは、Oracle の CONNECT BY ステートメントや SQLSQLER の CTE など、各データベースの再帰クエリ構文を通じて簡素化できます。