[MySQL(/PHP)] Weiterlaufende Abfrage

[chrissel]

Hey!
Ich habe mal eine Frage die hauptsächlich MySQL ist.
Gibt es eine Möglichkeit die Datensätze wie folgt auszulesen?

SELECT `id2`, `user` FROM `test` WHERE `id`='10'; // Gibt zurück: 5 ; test
SELECT `id2`, `user` FROM `test` WHERE `id`='5';  // Gibt zurück: 3 ; test2
SELECT `id2`, `user` FROM `test` WHERE `id`='3';  // Gibt zurück: 2 ; test3
SELECT `id2`, `user` FROM `test` WHERE `id`='2';  // Gibt nichts mehr zurück

Und sowas dann halt in einer Abfrage, so dass ich das per PHP mit while() auslesen kann.


Nachtrag:
Ich habe nämlich eine Tabelle "werberdaten". Dort wird jeder User eingetragen und wenn er ein Werber hat wird die ID in `wid` eingetragen. Nun möchte ich gucken ob der User mit der ID 5 z.B. den Werber 9 z.B. in irgendeiner Upline hat

 

[theHacker]

Die Lösung ist eine ordentliche Referal-Struktur, die Ref-Werber-Beziehungen in jeder Ebene erfasst.

Dann lautet die Query nur:

[FONT=Courier New][B][COLOR=#9932cc]SELECT[/COLOR][/B] `level`
[B][COLOR=#9932cc]FROM[/COLOR][/B] `referals`
[B][COLOR=#9932cc]WHERE[/COLOR][/B] `userid`=5 [B][COLOR=#9932cc]AND[/COLOR][/B] `werberid`=8[/FONT]

P.S. User-IDs sind Integer. Kapiert das denn hier niemand ?!

 

[chrissel]

Du meinst also das in der Tabelle von allen Refs auch deren Werber in Upline eintrage?
Dann wird die Tabelle doch bei vielen Usern viel zu groß . Oder verstehe ich das falsch?

Ich möchte ja "einfach" nur einen Check einbauen, der überprüft ob ein Werber bereits in der Upline eines Users ist

[..]P.S. User-IDs sind Integer. Kapiert das denn hier niemand ?!

Ich habe es mir angewöhnt überall immer ein ' zu setzten. Und ist es so schlimm wenn man das bei Integer Werten auch macht? Ich weiß zwar, dass es egal ist ob man die dort setzt oder nicht, aber ob es einen Unterschied macht (ausser den paar Bytes mehr im Code^^) wüsste ich nicht.

 

[theHacker]

Du meinst also das in der Tabelle von allen Refs auch deren Werber in Upline eintrage?
Dann wird die Tabelle doch bei vielen Usern viel zu groß . Oder verstehe ich das falsch?

Du scheinst richtig zu verstehen. Die Tabelle wird größer, aber sie ist ordentlicher. Der Datenbank selber is das egal. Die is für Milliarden Datensätze konzipiert, da stören 1000 lumpige Einträge wohl nicht die Bohne.

Ich habe es mir angewöhnt überall immer ein ' zu setzten. Und ist es so schlimm wenn man das bei Integer Werten auch macht? Ich weiß zwar, dass es egal ist ob man die dort setzt oder nicht, aber ob es einen Unterschied macht (ausser den paar Bytes mehr im Code^^) wüsste ich nicht.

Dann gewöhn dir das sehr schnell wieder ab
Der Unterscheid ist gravierend, da du die Datenbank zusätzlich doppelt beanspruchst und diese Belastung auch noch für die Katz is. Die Hochkommata bewirken ein Casten nach String, was für den Vergleich sofort wieder nach Integer zurückgecastet wird.
Es ist also alles andere, als egal !

 

[chrissel]

Du scheinst richtig zu verstehen. Die Tabelle wird größer, aber sie ist ordentlicher. Der Datenbank selber is das egal. Die is für Milliarden Datensätze konzipiert, da stören 1000 lumpige Einträge wohl nicht die Bohne.

Hm.. okay
Dann werde ich mal gucken was sich umstellen lässt.

Dann gewöhn dir das sehr schnell wieder ab
Der Unterscheid ist gravierend, da du die Datenbank zusätzlich doppelt beanspruchst und diese Belastung auch noch für die Katz is. Die Hochkommata bewirken ein Casten nach String, was für den Vergleich sofort wieder nach Integer zurückgecastet wird.
Es ist also alles andere, als egal !

Oh stimmt, ist eigentlich logisch ^^.
Dann werde ich mal mein Script durchsuchen ob ich soetwas noch iwo stehen habe

 

[chrissel]

Ich habe noch einmal eine Frage:
Also wenn es im Refsystem nur 3 Ebenen z.B. gibt, dann muss man ja eigentlich trotzdem ALLE Ebenen (also z.B. bis 20 oder wie tief das halt geht) in der Tabelle speichern oder?
Weil sonst kann man ja nicht überprüfen, ob der User bereits in irgendeiner Downline des Werbers (z.B. in Ebene 17) ist.

 

[ice-breaker]

Ich habe noch einmal eine Frage:
Also wenn es im Refsystem nur 3 Ebenen z.B. gibt, dann muss man ja eigentlich trotzdem ALLE Ebenen (also z.B. bis 20 oder wie tief das halt geht) in der Tabelle speichern oder?
Weil sonst kann man ja nicht überprüfen, ob der User bereits in irgendeiner Downline des Werbers (z.B. in Ebene 17) ist.

pro user nur ein feld für den direkten werber und dann hochhangeln. 20 Ebenen?

[FONT=Courier New][B][COLOR=#9932cc]SELECT[/COLOR][/B] `level`
[B][COLOR=#9932cc]FROM[/COLOR][/B] `referals`
[B][COLOR=#9932cc]WHERE[/COLOR][/B] `userid`=5 [B][COLOR=#9932cc]AND[/COLOR][/B] `werberid`=8[/FONT]

hmm, ein user der zugleich die userid 5 und 8 hat?

 

[theHacker]

Weil sonst kann man ja nicht überprüfen, ob der User bereits in irgendeiner Downline des Werbers (z.B. in Ebene 17) ist.

Wenn du nur 3 Ebenen hast, kann niemand einen Ref in Ebene 17 haben

hmm, ein user der zugleich die userid 5 und 8 hat?

Bitte die Query genau lesen
Ich selektiere die Ebene - sollte diese existieren -, in der der User mit der ID 5 Ref vom User mit der ID 8 ist.

 

[chrissel]

Wenn du nur 3 Ebenen hast, kann niemand einen Ref in Ebene 17 haben [..]

Doch klar geht das
Nur er merkt da nichts von weil nur die ersten 3 Ebenen angezeigt werden und vergütet werden.

Buchstaben Chaos:
Wenn User A z.B. User B als Ref hat und B hat C als Ref, usw. Dann ist in Ebene 25 von User A aus ja User Z
Nur wenn das jetzt so ist und User E z.B. nicht der Ref von D ist und ich E D zuordnen möchte, muss ich ja für jeden Ref von E auch einen Tabellen Eintrag machen für D.

Und nun überlege ich halt, ob ich wirklich für jeden Ref die ganze unvergütete Downline lang einen Tabelleneintrag machen muss.
Ich denke aber schon, denn sonst kann ich bei der Zuordnung nicht überprüfen, ob der User bereits in der (unvergüteten) Downline von deinem neuen Werber ist.

 

[theHacker]

Und nun überlege ich halt, ob ich wirklich für jeden Ref die ganze unvergütete Downline lang einen Tabelleneintrag machen muss.
Ich denke aber schon, denn sonst kann ich bei der Zuordnung nicht überprüfen, ob der User bereits in der (unvergüteten) Downline von deinem neuen Werber ist.

Wenn du die unvergütete Downline - also die Refebenen ignorierend - in der Datenbank speichern willst, dann halte ich das für übertrieben.
Wie oft musst du den kompletten "Refbaum" haben ? Für die paar Einzelfälle würde ich mir den zusammenrechnen.

Bedenke: Im worst-Case sind von n angemeldeten Usern (n-1) geworben worden, d.h. bei n Usern hast du (Summe(i=1 bis n-1) i) Einträge; mit dem kleinen Gauß ergibt sich quadratischer Platzverbrauch
Von der Rechenarbeit für ein Umordnung auch nur bei einem Ref gar nicht mal zu reden.

 

[ice-breaker]

Bitte die Query genau lesen
Ich selektiere die Ebene - sollte diese existieren -, in der der User mit der ID 5 Ref vom User mit der ID 8 ist.

*sich eine neue Brille kaufen geht*
sry ^^

 

[chrissel]

Wenn du die unvergütete Downline - also die Refebenen ignorierend - in der Datenbank speichern willst, dann halte ich das für übertrieben.
Wie oft musst du den kompletten "Refbaum" haben ? Für die paar Einzelfälle würde ich mir den zusammenrechnen.[..]

Okay Wäre nämlich wirklich etwas sehr viel.
Mit dem Überprüfen kann ich ja einfach erst gucken ob er in der sichtbaren Downline ist, wenn nein dann die nächst tieferen durch Schleifen checken.
Hm.. da stellt sich schon wieder die Frage, die ich im ersten Post habe^^
Kann man soetwas mit Hilfe einer/zwei/drei (halt möglichst wenig) Query(s) machen?
Wenn man alles per Schleife checken muss, kann es ja durchaus sein, dass dort 100 Querys ausgeführt werden...


@ice-breaker: So ne 10cm dicke Brille dürfte reichen

 

[ice-breaker]

@ice-breaker: So ne 10cm dicke Brille dürfte reichen

werde ich in Betracht ziehen

 

[theHacker]

Kann man soetwas mit Hilfe einer/zwei/drei (halt möglichst wenig) Query(s) machen?

Ich würde in diesem Fall dann mit WHERE 1 arbeiten und in PHP die "Durchhangel"-/Rechenarbeit machen.

 

[chrissel]

Ich würde in diesem Fall dann mit WHERE 1 arbeiten und in PHP die "Durchhangel"-/Rechenarbeit machen.

Also sind die vielen Querys egal?

 

[theHacker]

Also sind die vielen Querys egal?

Missverstanden Nur eine Query, die dir die komplette Tabelle liefert.
Das funktioniert natürlich nur, wenn PHP es vom Speicher her aushält. So viele User wie klamm wirst du aber ned in der Tabelle haben, von daher müsste das eigentlich schon gehen.

 

[chrissel]

[..]Missverstanden Nur eine Query, die dir die komplette Tabelle liefert.
Das funktioniert natürlich nur, wenn PHP es vom Speicher her aushält. So viele User wie klamm wirst du aber ned in der Tabelle haben, von daher müsste das eigentlich schon gehen.

Ah stimmt. So geht es auch gut


PS: Noch eben eine kurze Frage nebenbei, hat auch was mit MySQL zu tun, aber nicht direkt mit dem Thema:
Ist es besser wenn man eh schon ein paar Spalten bei jedem Seitenaufruf ausliest direkt mehrere auszulesen, oder später, wenn man die neuen Spalten auch braucht, diese dann auszulesen?

 

[theHacker]

Ist es besser wenn man eh schon ein paar Spalten bei jedem Seitenaufruf ausliest direkt mehrere auszulesen, oder später, wenn man die neuen Spalten auch braucht, diese dann auszulesen?

Du selektierst nur, was du brauchst. Deswegen soll man ja auch SELECT * nicht benutzen.

Baust du deine Seite aus und brauchst dann ein zusätzliches Feld, dann kannst du das ja im Nachhinein noch in die Query einsetzen.

 

[ZeroCCC]

Wenn du ein Baum rekrusiv abrufen willst empfiehlt es sich mit mysqli zu Arbeiten. Da hast du die möglichkeit mit prepared queries zu arbeiten, die sind für sowas gut geeignet. Die ganze Tabelle in die Anwendung zuladen ist nicht zu empfehlen... bei einem Script was nen paar hundert Benutzer hat geht das zwar, aber lass es mal nen paar mehr Benutzer werden. Alternativ kann man seit Mysql5.0 auch mithilfe einer Procedur das ganze Rekrusiv auslesen... sah aber in dem Artikel recht aufwendig auf und habs mir daher nicht genauer angeschaut. Ein anderer ansatz wäre mit Nested Sets zu arbeiten, da ist das Auslesen sehr performant, dafür sind sämtliche änderungen in der Struktur mit viel aufwand verbunden.

 

[chrissel]

Wenn du ein Baum rekrusiv abrufen willst empfiehlt es sich mit mysqli zu Arbeiten. Da hast du die möglichkeit mit prepared queries zu arbeiten, die sind für sowas gut geeignet. Die ganze Tabelle in die Anwendung zuladen ist nicht zu empfehlen... bei einem Script was nen paar hundert Benutzer hat geht das zwar, aber lass es mal nen paar mehr Benutzer werden. Alternativ kann man seit Mysql5.0 auch mithilfe einer Procedur das ganze Rekrusiv auslesen... sah aber in dem Artikel recht aufwendig auf und habs mir daher nicht genauer angeschaut. Ein anderer ansatz wäre mit Nested Sets zu arbeiten, da ist das Auslesen sehr performant, dafür sind sämtliche änderungen in der Struktur mit viel aufwand verbunden.

Hast du eventuell einen Link für sowas da?
Ich finde kein Tutorial oder ähnliches so für MySQLi. Und ich habe mit MySQLi noch nie gearbeitet
Also zurzeit gebe ich den Baum bei der Refübersicht mit Hilfe einer Funktion aus, welche sich immer wieder aufruft, bis die Refebenen durch sind.
Nur würde ich das gleiche machen für die Upline (auch unvergütete) dann würde ich ja auf sehr viele Querys kommen. Deswegen suche ich ja "einfach" eine Query mit der man das auslesen kann.


Ich glaube ich habe es aber selber gut rausbekommen:

Ich habe gelesen, dass man mit MySQL Variablen verwalten kann, (@var:=`spalte`).
Man könnte doch dann die Query so gestalten:

SET @wid = 2;
SELECT @wid:=`uid` AS `uid` FROM `refs` WHERE `wid`=@wid AND `ebene`=1;