Wie ist die Datenstruktur des dreistufigen Rabattsystems? Probleme ändern und abfragen

Wir müssen ein dreistufiges Rabattprojekt durchführen. Die Anforderung besteht darin, die Benutzer der ersten, zweiten und dritten Ebene einer Person anzuzeigen und den Vorgesetzten dieser Person ändern zu können so:
uid 1 2 3
Benutzer-ID gehört dem Vorgesetzten, gehört dem Vorgesetzten, gehört dem Vorgesetzten, Vorgesetzten
1 0 0 0
2 1 0 0
3 2 1 0
4 3 2 1
5 4 3 2
6 3 2 1

Der Vorgesetzte von Benutzer 1 ist die Plattform, und die drei übergeordneten Ebenen sind alle 0. Der Vorgesetzte von Benutzer 6 ist Benutzer 3, sein Vorgesetzter ist 2 und sein Vorgesetzter ist 1. Diese Struktur ist praktisch für Abfragen, wenn Sie jedoch den Standard-Vorgesetzten ändern Wenn diese Person 100.000 Untergebene hat, müssen auch die Vorgesetzten dieser 100.000 Personen Änderungen vornehmen, und der Änderungsbetrag wird zu groß sein.
Bei Änderung in:
uid 1
Benutzer-ID gehört zum Vorgesetzten
1 0
2 1
3 2
4 3
5 4
6 3
Um alle Benutzer auf der dritten Ebene abwärts von diesem Benutzer abzufragen, müssen Sie zuerst alle Benutzer der zweiten Ebene des Benutzers abfragen und dann alle untergeordneten Benutzer aller Benutzer der zweiten Ebene abfragen Das Volumen ist auch sehr groß.
Möchten Sie fragen, ob Sie Kompromisslösungen haben?

Antwortinhalt:

Wir müssen ein dreistufiges Rabattprojekt durchführen. Die Anforderung besteht darin, die Benutzer der ersten, zweiten und dritten Ebene einer Person anzuzeigen und den Vorgesetzten dieser Person ändern zu können so:
uid 1 2 3
Benutzer-ID gehört dem Vorgesetzten, gehört dem Vorgesetzten, gehört dem Vorgesetzten, Vorgesetzten
1 0 0 0
2 1 0 0
3 2 1 0
4 3 2 1
5 4 3 2
6 3 2 1

Der Vorgesetzte von Benutzer 1 ist die Plattform, und die drei übergeordneten Ebenen sind alle 0. Der Vorgesetzte von Benutzer 6 ist Benutzer 3, sein Vorgesetzter ist 2 und sein Vorgesetzter ist 1. Diese Struktur ist praktisch für Abfragen, wenn Sie jedoch den Standard-Vorgesetzten ändern Wenn diese Person 100.000 Untergebene hat, müssen auch die Vorgesetzten dieser 100.000 Personen Änderungen vornehmen, und der Änderungsbetrag wird zu groß sein.
Bei Änderung in:
uid 1
Benutzer-ID gehört zum Vorgesetzten
1 0
2 1
3 2
4 3
5 4
6 3
Um alle Benutzer auf der dritten Ebene von diesem Benutzer abzufragen, müssen Sie zuerst alle Benutzer der zweiten Ebene des Benutzers abfragen und dann alle untergeordneten Benutzer aller Benutzer der zweiten Ebene abfragen Auch das Abfragevolumen ist sehr groß.
Möchten Sie fragen, ob Sie Kompromisslösungen haben?

MySQL-Fremdschlüsselrekursion

Es wird empfohlen, die zweite Lösung zu übernehmen und nur die beiden Felder uid und pid beizubehalten. Dieses Design unterstützt alle Ebenen von Beziehungen, und wenn es eine Aktualisierung gibt, wird die Anzahl der geänderten Datensätze relativ gering sein.
Mehrstufige Abfragen können durch die rekursive Abfragesyntax jeder Datenbank vereinfacht werden, z. B. die CONNECT BY-Anweisung in Oracle oder den CTE von SQLSQLER usw.