Transaktionsliste - auch nach Nicks suchen

[Hamsta]

Ich find es blöd, dass man in der Transaktionsliste nur nach Klammids suchen kann. So muss ich immer erst die Usersuche bemühen und die Klammid kopieren.

Es würde das ganze doch viel einfacher machen, wenn man einfach nach Nicks suchen könnte

[Lach]

Aber da stellt sich doch das pro. das man seinen nick ändern kann..
und somit "falsche" Daten dir gegeben werden könnten..?
oder habe ich da gerade ein Denkfehler?

[tobias1985]

@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.

[klamm]

Das klingt mir nach "wird langsamer".

Bei Der Größe der Transaktions-DB isses nicht unerheblich, ob ich nach indextierten Zahlen suche oder nach Textstücken. Ich versuch ma, ob ich was dahingehend optimiertes hinbekomme.

[tobias1985]

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...

[klamm]

Wenn ihr nur direkte Suchen auf User wollt, dann geht das so, jo.
Ich dachte nur konsequenterweise sowas wie:

*bias19*

... was dann u.U. auch versch. User findet.

[tobias1985]

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.

[klamm]

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.

[tobias1985]

Zitat von klamm

Wenn dann werde ich es machen wie bei jeder normalen Suche.
Also full-featured mit Joker.

Ok, wollte dir nur die Arbeit "ersparen". Aber so ists natürlich dann das Optimum.

Zitat von klamm

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?

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.

Zitat von klamm

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.

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?

[klamm]

Zitat von tobias1985

Ein Nachteil ist auch, dass ich dann nicht alle Transaktionen eines Users angezeigt bekomme

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.

[paddya]

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:

Zitat von klamm

Ich hab aber gerne so wenig DB-Abfragen wie möglich.

Es ist aber ein Irrglaube, dass wenige Queries automatisch schneller sind

[klamm]

Zitat von paddya

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 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.

Es ist aber ein Irrglaube, dass wenige Queries automatisch schneller sind

Das stimmt.

[klamm]

Fertig.

Voll funktionsfähig inkl. Joker.
Und schnell.

[charts]

Meine DA-Transaktionen (Loseeinnahmen) tauchten heute zum DA-Termin nicht mehr in der Transakkiliste auf obwohl die Lose auf dem Konto landeten. Hängt das möglicherweise mit der neuen Anpassung zusammen?

[klamm]

Transaktionen