[MySQL] Ref System mit nested Set´s

[strolch00]

Hi @all,

versuche gerade nen Refsystem mit den oben genannten umzusetzen. Als Grundlage habe ich diese Seite.

Jetz habde ich nur einige verständnis Probleme, erstens gehe ich richtig in der annahme das jeder User ohne Werber ein Wurzelelement wie in dem Beispiel die Säugetiere sind??

Und ist es überhaupt möglich damit ein Refsystem umzusetzen welchen begrenzte Ebenen hat, zB 4 oder nur 3.

Bin darauf gestoßen aufgrund des Threads bzw post von veers.

*edit
Achso meine Strucktur der Tabelle sieht aktuell so aus:

CREATE TABLE IF NOT EXISTS `refferal` (
  `advertiser_id` int(4) unsigned default NULL,
  `lft` int(4) unsigned NOT NULL,
  `user_id` int(4) unsigned NOT NULL,
  `rgt` int(4) unsigned NOT NULL,
  KEY `lft` (`lft`,`rgt`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

user_id und advertiser_id ist die id der User Tabelle, wobei advertiser_id zB meine ID die 2 wäre und ich mit dieser schaue welche user_id´s ich als ref habe.

Denke das das so korrekt ist, aber über Meinungen bin ich dankebar.
Danke

*edit 2
Ich habe auch noch eine Übersicht dazu gefunden, das ist glaube ich genau so etwas was ich brauche, wenn man die Übersichtstabelle anschaut.

 

[ice-breaker]

Und ist es überhaupt möglich damit ein Refsystem umzusetzen welchen begrenzte Ebenen hat, zB 4 oder nur 3.

nein, weil alles was darüber hinaus geht muss keine baum form mehr haben, ich mache da mal nen beispiel:

user1
-> user 2
-> user 3
-> user 4
-> user 5
-> user 6

user 1 hat also in ebene 1 den user2, in ebene 2 den user3 usw. Da wir nur 4 Ebenen haben, ist user 5 sein letzter Ref, user6 geht schon über das System hinaus.
User 6 hat aber nun wiederum User 1 als Ref (hat ihn sich nachtragen lassen) das verstößt nicht gegen die normalen Ref-Regeln, nur gegen die Baumstruktur.
Sollte man ihm nachhinein an der Struktur nix ändern wollen (was hier ja in klamm wohl eher weniger der fall ist) kannst du das natürlich nehmen

 

[strolch00]

Hallo Ice,

und was hat veers dann in diesem Thread damit gemeint?

Also nachtragen des User 1 hatte ich nicht vor aber ausschließen kann man nie alles gell, welches System soll man denn dann verwenden. Das Pfadsystem finde ich auch doof und das letzte vorgestellte System von flaschenkind finde ich teils sehr verwirrend und nicht sicher. Eine falsche Eintragung der unteren Refs und das system ist instabil. Kennst Du vielleicht noch einen guten Link zu einer Systembeschreibung?

Danke

 

[DaPhreak]

und das letzte vorgestellte System von flaschenkind finde ich teils sehr verwirrend und nicht sicher. Eine falsche Eintragung der unteren Refs und das system ist instabil.

Aus langjähriger Erfahrung mit Scripten auch für größere Paid4's kann ich Dir versichern, dass das ein sehr gutes, flexibles und vor allem robustes System ist. Downlineerhaltung ist automatisch drin, Anzahl Refebenen lässt sich zur Laufzeit ändern, detaillierte Statistiken wer auf welcher Ebene wieviel Refverdienst erhalten hat und wer wann zuletzt aktiv war, all das lässt sich sehr komfortabel machen. Nebenbei ist das System ziemlich performant weil man sich zu keinem Zeitpunkt manuell "durch die Ebenen durchhangeln" muss und alle Queries reine SELECTs sind (kein GROUP nötig). Einziger kleiner Nachteil ist vielleicht, dass es natürlich etwas redundant ist und damit insgesamt mehr Speicherplatz belegt. Aber mit vielen Zeilen kommt MySQL ganz gut klar, und man speichert ja im einfachsten Falle nur IDs, das ist nicht so riesig dann.

Vielleicht kannst Du erklären was Du mit "nicht sicher" und mit der "falschen Eintragung" meinst.

 

[strolch00]

Zur Erklärung mit "nicht sicher" meine ich, zB bei einer Refumschreibung.
Man muss ja wirklich alle Ebenen umschreiben(unter umständen bis zu 10 Zeilen, bei 10 Ebenen) wenn man einen ref rausnimmt, oder liege ich da falsch? (Hatte es vorhin nur flüchtig angeschaut)

Ist es nicht einfacher immer nur eine Zeile einzutragen von der jeweiligen User_id. In welcher Ebene diese jeweil sind eribt sich doch alleine oder. Wobei dadurch die Select Query wieder komplizierter wird.

 

[DaPhreak]

Ja, Ref umschreiben ist bissl fummelig, zumindest wenn der ganze Baum umgehängt werden soll. Aber so schlimm ist es auch nicht, kriegt man schon hin. Sind halt recht viele Anfragen.

Nur kommt Ref umschreiben halt auch ziemlich selten vor, deshalb ist die Anzahl der dafür benötigten Anfragen eigentlich egal.

Wichtig ist, dass das was sehr häufig passiert performant ist. Und da ist v.a. der schnelle Zugriff auf die Ebenen wichtig. Bei jeder Vergütung muss das ja überall eingefügt werden und Vergütungen sind was was bei Paid4's wirklich wirklich viel passiert. Das muss unbedingt so performant wie möglich sein.


Ein weiteres Problem mit der Variante "nur eine Zeile" ist, dass dann die Downline zerstört wird, wenn sich jemand abmeldet... da muss man dann halt die Downline reparieren beim Abmelden. Das meinte ich mit "robust", das von mir favorisierte System stört das gar nicht, wenn sich mal jemand abmeldet.

 

[strolch00]

Ah stimmt an die DL Erhaltung habe ich gar nicht gedacht, das ist natürlich wieder ein Argument dafür.

Ich habe zu der Tabelle auch noch eine Frage, für das zusammenrechnen der einzelnen Umsätze, wäre es nicht hilfreich noch eine Spalte mit dem bissherigen Umsatz einzufügen, bzw ne Spalte mit ID, mit der Ich in einer anderen tabelle die Umsätze Plegen kann?

Weil die Refübersicht mit Umsatz anzeige ich ja auch noch eine Sache die sehr oft und schnell statt finden sollte.

Ich danke euch erstmal für die Antworten, und werde nun mal ein paar Tests durchführen.

 

[DaPhreak]

wäre es nicht hilfreich noch eine Spalte mit dem bissherigen Umsatz einzufügen

Kurz und knapp: Ja, ist es.
Das ist grad der Vorteil an dem System, man kann hier pro Zeile noch solche Dinge wie Umsätze oder letzte Aktivität speichern. Ich hatte dort sogar drei Spalten drin mit drei verschiedenen Umsatzarten, da konnte man dann gut sehen welcher Ref was macht. Paar Spalten verträgt die Tabelle schon noch, sollte halt nur nicht zu sehr ausarten. Finde ich jedenfalls.