[MySQL] Komplizierte MySQL Query

[flaschenkind]

Ich und meine Querys ^^

Ich habe folgende Datenbankstruktur (hat Tleilax im Crashforum vorgeschlagen):

Tabelle refs:
userid | level | werber
1 | 1 | 0
2 | 1 | 1
3 | 1 | 2
3 | 2 | 1
4 | 1 | 1
...

Das soll ein guter Aufbau für ein Refsystem sein. Hab ich mal vor langer Zeit gelesen und hatte den Aufbau noch gespeichert.
Dazu hab ich die Tabelle user
id | username
1 | test
2 | test2
3 | test3
4 | test4
...

das sind jetzt nicht alle felder, aber ich brauche nur den Username


Wenn realisiere ich damit jetzt am besten eine Downline? Die müsste dann so für test aussehen:
Ebene 1:
test2 (weil test2 von test geworben wurde), test4 (weil test4 von test geworben wurde)
Ebene 2:
test3 (weil test3 von test2 (ebene 1) geworben wurde)

 

[theHacker]

Für die Downline brauchst du pro Ebene eine Query, die alle Werber/Ref-Beziehungen abruft.

(So hab ichs zumindest in Erinnerung, wie man bei diesem Datenbank-Aufbau vorgehen muss)

 

[flaschenkind]

Das wären dann 15 Abfragen. Aber das mit den Refs kann ja auch in eine andere Richtung gehen, das werden dann aber doch mehr Abfragen oder?

 

[ice-breaker]

Ich würde es folgendermaßen machen:

Query1: lies alle Refs der 1. ebene aus
Query2: lies alle refs von den refs aus query1 aus (mit referenz auf den werber von 1)
Query3: das gleiche wie 2


Edit: wofür brauchst du das Level eines Refs? das ist doch nur speichern von doppelten Daten, es würde doch vollkommen reichen einfach nur den werber jeder Person zu speichern

 

[theHacker]

Edit: wofür brauchst du das Level eines Refs? das ist doch nur speichern von doppelten Daten, es würde doch vollkommen reichen einfach nur den werber jeder Person zu speichern

Nein, das Level ist entscheidend in diesem System, da es Teil des PRIMARY-Keys ist
Guck dir mal tleilax's Post dazu an.

 

[Johnson]

Ich würde das mit einem Self-Join lösen.

SELECT * FROM user AS u1
LEFT JOIN user AS u2 ON u2.werber = u1.user_id
WHERE u1.werber = 1

Liefert bei meinem Test z.B.

user_id werber name user_id werber name
2 1 u2 NULL NULL NULL
3 1 test 4 3 teeeest
3 1 test 5 3 hhhhujuuu

zurück.

edit: so wie ich das jetzt sehe ist das Obige nicht mehr zu gebrauchen

 

[flaschenkind]

[...]

Hast recht, geht nicht

ice-breaker's Lösung teste ich gleich mal.

 

[tleilax]

Öhrm, versteh ich grad die Problematik nicht? Du hast bislang nirgends gesagt, dass man sehen können soll, welcher Ref welchen Ref eine Ebene drunter geworben hat. Und insofern reicht dieses Query vollkommen aus:

SELECT userid, level
FROM refs
WHERE werber = <gesuchte_userid>
ORDER BY level ASC

Damit kriegst Du alle Refs eines Users über alle Ebenen. Die Beziehungen der Refs untereinander gehen natürlich verloren, aber wenn man's ganz genau nehmen will, würde ich an dieser Stelle auch erstmal jemanden fragen, der sich mit Datenschutz auskennt, um die Frage zu klären, ob man als User überhaupt sehen dürfte, welcher direkte Ref von einem wiederum wen geworben hat.

Die Aufarbeitung des Results ist dann recht simpel in PHP zu erledigen.

 

[flaschenkind]

Da sieht man den Wald vor lauter Bäumen nicht -.-
Vielen Dank

 

[ActionScripter]

Tabelle refs:
userid | level | werber
1 | 1 | 0
2 | 1 | 1
3 | 1 | 2
3 | 2 | 1
4 | 1 | 1
...

Das soll ein guter Aufbau für ein Refsystem sein. Hab ich mal vor langer Zeit gelesen und hatte den Aufbau noch gespeichert.
Dazu hab ich die Tabelle user
id | username
1 | test
2 | test2
3 | test3
4 | test4
...

warum löst ihr hier die ref-werber-frage immer in zwei tabellen?
ich speichere einfach zu jedem user nur seinen werber und das direkt bei den userdaten. mit ein paar abfragen kann ich dann die refs jeder ebene herausbekommen und das ohne jegliche tiefenbeschränkung ... oder hab ich nen denkfehler?

 

[theHacker]

@ActionScripter:
Du hast keinen Denkfehler, aber dieses System - was man leider was in jedem Billigscript findet - ist nicht besonders clever.

- Du brauchst zu viele Abfragen, die man im anderen System in eine Query zusammenfassen hätte können.
- Refback wie Refstatistiken sind nur in einer 1:1-Beziehung möglich, nicht auf der ganzen Downline.
- Refinfos in der Usertabelle sind nicht besonders gut, weil man Inhalte ja trennen sollte
- ...

 

[Johnson]

- Du brauchst zu viele Abfragen, die man im anderen System in eine Query zusammenfassen hätte können.
- Refback wie Refstatistiken sind nur in einer 1:1-Beziehung möglich, nicht auf der ganzen Downline.

Schau mal meine Query oben an (die hier vom Tabellendesign leider fehl am Platze ist), damit sollte das alles auch in einer Query und in Downlines gehen

Gruß

 

[ActionScripter]

@ActionScripter:
Du hast keinen Denkfehler, aber dieses System - was man leider was in jedem Billigscript findet - ist nicht besonders clever.

was jetzt meins, oder zwei tabellen?

- Du brauchst zu viele Abfragen, die man im anderen System in eine Query zusammenfassen hätte können.

die meisten sachen kann ich auch bei mir in einem query machen... siehe johnsons query, den ich in ähnlicher form dazu benutze... im extremfall brauch ich einen query pro ref-ebene

- Refback wie Refstatistiken sind nur in einer 1:1-Beziehung möglich, nicht auf der ganzen Downline.

die statistiken stehen auch nicht beim user, die sind natürlich getrennt.

- Refinfos in der Usertabelle sind nicht besonders gut, weil man Inhalte ja trennen sollte

naja schon, aber auch den mittelweg zu schnellen queries finden. ich habe in meiner user-tabelle alle benötigten angaben, die ich für den betrieb brauche und die ich nur selten zurückschreiben muss.

das wären: userID, options (ne bitmask für diverse flags), nick, pass, mail, klammid, werber, refback und message (beinhaltet gesperrt-meldung etc.)

alle zusätzlichen oder schreibintensiven daten sind in weiteren tabellen für statistik, userdaten, userverhalten etc. untergebracht. ist das ein unlogischer aufbau und "nicht clever"??

 

[ice-breaker]

Also ich nutze auch die Methode wie ActionScripter (Mist ) weil auch im Konzept der Normalisierung gesagt wird, man soll doppelte Daten vermeiden, warum soll ich zu einem User seinen Werber 1 und Werber 2 speichern, wenn ich über weitere Abfragen oder Joins den Werber 2 heruasbekommen.
Zudem sind Änderungen in unserem System weit leichter vorzunehmen, da wir nicht soviele Spalten anpassen müssen, und auch das Übertragen von Ref-Bäumen gestaltet sich einfacherer, da Wir nur den Werber1 und nicht auch noch Werber2 ändern müssen

 

[tleilax]

weil auch im Konzept der Normalisierung gesagt wird, man soll doppelte Daten vermeiden

Bei vielen Dingen ist eine gewisse Denormalisierung gar nicht so unangebracht. Bei jeder Gutschrift über mehrere Ebenen müssen bei Euch mehrere Queries mittels JOINs über die Tabellen laufen. Um die Joins zu vermeiden, bin ich eben zu diesem Konzept gekommen.