Transaktionsliste - auch nach Nicks suchen
- Ersteller Hamsta
- Erstellt am
tobias1985
Der Erlöser
- 24 April 2006
- 4.963
- 607
@Lach: Ja hast du. Es wäre technisch gar kein Problem, auch nach Usernamen suchen zu lassen. Zur Transaktion wird bestimmt immer nur die UserID (klammID) gespeichert. Gibt man nun einen Usernamen ein, ermittelt eine Abfrage die passende KlammID und sucht dann damit alle passenden Transaktionen.
Na vielleicht macht Lukas ja die kleine Änderung.
Wäre schon praktisch.
Na vielleicht macht Lukas ja die kleine Änderung.
Wäre schon praktisch.
tobias1985
Der Erlöser
- 24 April 2006
- 4.963
- 607
Warum nach Textstücken?
Du musst doch nur zur Eingabe die passende KlammID ermittelt und dann in der Transaktionstabelle so weitersuchen, wie bisher.
Ok, es wird eine SQL-Abfrage mehr, um die KlammID zu ermitteln...
Du musst doch nur zur Eingabe die passende KlammID ermittelt und dann in der Transaktionstabelle so weitersuchen, wie bisher.
Ok, es wird eine SQL-Abfrage mehr, um die KlammID zu ermitteln...
tobias1985
Der Erlöser
- 24 April 2006
- 4.963
- 607
Ah ok. Hm, ok das wäre auch lösbar, aber natürlich wieder Aufwand.
Man kann einen Usernamen eingeben. Wird dieser Direkt gefunden, kannst du es so machen, wie in meinem letzten Post beschrieben.
Sucht man nach *bias19* wie in deinem Beispiel und würde das mehr als 1 User als Treffer ergeben, bekommt man eine Liste der Treffer angezeigt. Klickt man einen Usernamen an, wird die Suche mit dem angeklickten User gestartet.
Man kann einen Usernamen eingeben. Wird dieser Direkt gefunden, kannst du es so machen, wie in meinem letzten Post beschrieben.
Sucht man nach *bias19* wie in deinem Beispiel und würde das mehr als 1 User als Treffer ergeben, bekommt man eine Liste der Treffer angezeigt. Klickt man einen Usernamen an, wird die Suche mit dem angeklickten User gestartet.
Wenn dann werde ich es machen wie bei jeder normalen Suche.
Also full-featured mit Joker.
D.h. *obias19* findet dann alle Transaktionen von "Dobias1999" und "tobias1985", wie jedes andere Suchergebnis auch chronologisch nach Transaktionszeitpunkt geordnet. Das Jokern geht übrigens jetzt mit IDs auch schon.
Man muss halt die Accounts-Tabelle dranjoinen dazu, um an den Nickname zu kommen. Bisher genügt es, sich auf die Transaktionstabelle zu beschränken. Das ist das, was Ärger machen könnte. Aber lass das mein Problem sein ...
Edit: Angenommen man sucht nach Nicknames (genau dann, wenn das ID-Feld keine Zahl-only enthält). Was passiert denn dann mit den EF-Transaktionen? Soll da automatisch statt nickname in der kennung gesucht werden? Wäre das konsequenteste, oder?
Edit2: Performante, aber unschöne Lösung: Zum Zeitpunkt der Transaktion die EF-Kennung und den Nickname fest wegschreiben in die Transaktionsliste (wird aktuell dynamisch ermittelt). Nachteil: Wenn jemand den Nick ändert (Kennung kann man nicht ändern) steht in der Transliste evtl. der alte Nick bei alten Transaktionen. Ich glaube aber das könnte man verschmerzen wenn es dafür schnell bleibt. Oder man schreibt das halt bei Nick-Änderung mit um. Kommt ja kaum vor.
Also full-featured mit Joker.
D.h. *obias19* findet dann alle Transaktionen von "Dobias1999" und "tobias1985", wie jedes andere Suchergebnis auch chronologisch nach Transaktionszeitpunkt geordnet. Das Jokern geht übrigens jetzt mit IDs auch schon.
Man muss halt die Accounts-Tabelle dranjoinen dazu, um an den Nickname zu kommen. Bisher genügt es, sich auf die Transaktionstabelle zu beschränken. Das ist das, was Ärger machen könnte. Aber lass das mein Problem sein ...
Edit: Angenommen man sucht nach Nicknames (genau dann, wenn das ID-Feld keine Zahl-only enthält). Was passiert denn dann mit den EF-Transaktionen? Soll da automatisch statt nickname in der kennung gesucht werden? Wäre das konsequenteste, oder?
Edit2: Performante, aber unschöne Lösung: Zum Zeitpunkt der Transaktion die EF-Kennung und den Nickname fest wegschreiben in die Transaktionsliste (wird aktuell dynamisch ermittelt). Nachteil: Wenn jemand den Nick ändert (Kennung kann man nicht ändern) steht in der Transliste evtl. der alte Nick bei alten Transaktionen. Ich glaube aber das könnte man verschmerzen wenn es dafür schnell bleibt. Oder man schreibt das halt bei Nick-Änderung mit um. Kommt ja kaum vor.
tobias1985
Der Erlöser
- 24 April 2006
- 4.963
- 607
Ok, wollte dir nur die Arbeit "ersparen".
Aber so ists natürlich dann das Optimum. Wenn man aktuell mit der Maus über die EF-ID in den Transaktionen geht, was wird da angezeigt? Die Kennung oder? Wenn ja, dann wäre das schon gut so. Denn ich will ja zum Beispiel nach "superslots" suchen können. Aktuell muss ich mir immer die EF-ID rauskopieren.
Musst du wissen. Ja es ist unschön, wenn man (änderbare) Usernamen in der Tabelle extra speichert.
Ein Nachteil ist auch, dass ich dann nicht alle Transaktionen eines Users angezeigt bekomme, falls dieser seinen Namen geändert hat. Dann muss ich X mal suchen nach X verschiedene Usernamen. (ok, dürfte selten vorkommen)
Ist es so unperformant, die ID zum Usernamen zu ermitteln?
Doch, Du kannst ja weiterhin die ID nehmen in diesem seltenen Fall. Ok Du weißt es evtl. nicht ob er den Namen geändert hat. Ich würde daher dazu tendieren, bei Namensänderung halt die Transaktionsliste mit zu updaten. Ist ja nur 1 Stelle.
Die Transaktionstabelle hat mehrere Millionen Einträge. Wenn ich zu dieser Megatabelle noch 2+ weitere Tabellen dazujoinen muss, kann das durchaus langsam werden. OK man könnte auch vorab Queries machen und auf die Transliste dann nur die gefundenen IDs loslassen. Ich hab aber gerne so wenig DB-Abfragen wie möglich.
Edit: Wie ich grad sehe, speichere ich Nick und Kennung schon seit jeher in der Transliste. Hatte mir wohl schonmal Gedanken zur Performance gemacht.
Warum ermittelst du nicht in einer Abfrage die Klamm- und EF-IDs, die auf den eingegebenen Usernamen matchen und verwendest die dann in der Query, die die Transaktionen ermittelt (Index kann dann verwendet werden).
Ich weiß ja nicht, wie performant deine User-Suche ist, aber die Performance der Transaktionsabfrage sollte darunter nicht leiden, da ja eh der Index verwendet werden kann. Kannst es dir also meiner Meinung nach sparen, den Usernamen zusätzlich zu speichern.
Greetz
paddya
Edit:
Ich weiß ja nicht, wie performant deine User-Suche ist, aber die Performance der Transaktionsabfrage sollte darunter nicht leiden, da ja eh der Index verwendet werden kann. Kannst es dir also meiner Meinung nach sparen, den Usernamen zusätzlich zu speichern.
Greetz
paddya
Edit:
Es ist aber ein Irrglaube, dass wenige Queries automatisch schneller sind
Ich finde es irgendwie unschön, dass man dann übergroße Mengen bekommen kann. Ob das mysql was macht weiss ich nicht, aber "select * from table where id IN (_menge_mit_250.000_ids_)" sieht für mich irgendwie gefährlich aus, rein von der query-Länge her. Obwohl ich das bei der User-Suche auch so mache seh ich grad.
Immerhin müssen diese Mengen an PHP gesendet werden (anderer Server) und dann wieder zurück zu mysql - sofern es sich nicht mit subqueries lösen lässt.Da ich nick/ef-kennung aber sowieso schon seit eh und je speicher, nur bisher nicht verwendet habe, kann ich das jetzt auch dazu nutzen. Zudem bekommst Du so auch Matches auf Transaktionen von Usern, die sich schon abgemeldet haben, über eine Vorab-Query also nicht auffindbar wären.
Das stimmt.Es ist aber ein Irrglaube, dass wenige Queries automatisch schneller sind
