Lösungsversuch 1 zu #159

[JohannMaierhofer]

Ich habe einmal versucht das Problem welches in #159 beschrieben ist zu lösen. Da ich aber auch kein SQL Experte bin kann ich nicht sagen ob das jetzt schneller ist. Ich glaube aber schon. Falls es einen Match mit einem Mitglied gibt braucht man jetzt nur genau zwei Datenbank Queries. Mein Vorschlag wäre, ihr schaut euch das mal an und wenn es ok ist könnten wir einen Nightly Build machen. Dann könnte Lukas es einmal ausprobieren. Was ich gemacht habe ist Folgendes:

• Als erstes mache ich ein Query auf Mitglieder bei denen ein Mitgliedskonto existiert. Die anderen brauchen wir ja nicht. Gleichzeitig wirden die Mitglieder schon so ausgewählt, dass sie die Bedingung nach Fehlbetrag oder Überzahlung erfüllen.
• Im RS lese ich gleich die ID, den Namen und Vornamen des Mitglieds. Dadurch muss ich keine Queries auf das Mitglied machen. Ich speichere die Daten in meiner privaten MyMitglied Klasse.
• Anschliesend läuft der Matchalgorithmus wie gehabt. Wenn es einen Match gibt bleibt hier ein Mitglied übrig, ansonsten alle.
• Um die Mitgliedskonten zu suchen nutze ich für jedes gefundene Mitglied den MitgliedskontoQuery den es schon gab. Der findet in einem Query alle Mitgliedskonten des Mitglieds welche den gewählten Bedingungen entsprechen. Wurde also vorher ein einziges Mitglied gefunden gibt es nur noch ein weiteres Query.
• Also haben wir im Normalfall wo es einen Mitglieder Match gibt insgesamt nur zwei Queries.

Sonstige Anmerkungen:

• Ich habe die Texte in den Laschen geändert, vorher hatte ich irgenwie keine Ahnung was mir die Titel sagen sollten
• Das Datums Handling habe ich gelassen weil es im Mitgliedskonten View ja benutzt wird
• Den Vergleich mit dem Zweck habe ich gelöscht weil er eigentlich keinen Sinn macht. Kann man aber immer wieder leicht einfügen wenn trotzdem man der Wunsch auftaucht
• Bisher wurden nur Namen verglichen die mehr als drei Buchstaben hatten. Ich hatte aber auch einen Namen mit nur drei Buchstaben. Der wurde dann nicht gefunden. Ich habe das jetzt auf mehr als zwei Buchstaben geändert.

Ich hoffe mal, meine Arbeit hat sich gelohnt. Zumindest ist der Code jetzt besser verständlich.

[dippeal]

Was die queries angeht ist es jetzt deutlich weniger. Dem Match auf Zweck finde ich auch nicht nötig, da man bereits über den Namen und den Betrag eine gute Eingrenzung hat.

[JPT77]

Kann ich jetzt hier den PR kommentieren oder woanders? Ich habe jetzt nicht wirklich den Überblick und kann auch falsch liegen. Ich will trotzdem mal mein Feedback geben.

Du machst also von vornherein einen join über M, MK und B. SUM(BETRAG) ist eine elegante Lösung!

Allerdings holst du ja garnicht den MK.BETRAG? Womit vergleichst du?

Dann machst du eine Java-schleife über alle MK, weil es mehr Aufwand wäre, erst die M zu holen? Dir ist schon klar, dass du hier potentiell eine Schleife über 10.000 Datensätze machst? und diese müssen ja auch alle per SQL geholt werden. Ich denke, die Software wird das Blockweise holen... hoffentlich... aber mehr als ein Zugriff ist es sicher.

"Nur Ist-Buchung erzeugen" - sollte das nicht heißen: IST Buchung verknüpfen mit: existierendem SOLL / neu erstelltem SOLL finde SOLL / erstelle SOLL

Vielen Dank für dein Engagement!

Jan

[JohannMaierhofer]

Hallo Jan, Der Vergleich passiert im SQL Statement. Ja, die Schleife geht über die Mitgliedskonto aber nur über solche die die Bedingung Überzahler oder Fehlbetrag haben. Aber ja, da müssen wohl alle gelesen werden. Ist dann wohl doch besser nur alle Mitglieder zu holen.

Inzwischen habe ich einen weiteren Vorschlag der wahrscheinlich besser ist. Siehe #184

[JohannMaierhofer]

Ich habe jetzt den Code nochmals auf Grund der Kommentare von Jan angepasst. Danke für die Kommentare. Ich lese jetzt die Mitglieder aus wenn die Differenz auf EGAL steht. Damit geht die Schleife maximal über die Anzahl der Mitglieder. Das macht es doch deutlich schneller in diesem Fall. Im Fall von FEHLBETRAG oder UEBERZAHLUNG lasse ich den alten Request. Da die Datenbank den Check macht ist die Anzahl in der Schleife so groß wie Mitgliedskonten (Soll-Buchungen) existieren die diese Bedingung erfüllen. Ich nehme jetzt einmal an, dass bei FEHLBETRAG die Anzahl nicht viel größer ist als die Anzahl der Mitglieder und nach Zahlungen der Mitglieder und erfolgten Zuordnungen die Anzahl immer kleiner wird.

PS: Den Text in den Laschen habe ich auch nochmals geändert.

[JohannMaierhofer]

Im MitglideskontoQuery wurden Logger Ausgaben gemacht die man nicht wirklich braucht aber auch alles langsamer machen. Ich habe sie auskommentiert.

[JohannMaierhofer]

Ich denke, man muss auch den Mitgliedskonten Dialog und den MitgliedskontenZuordnung Dialog anpassen. Ich habe festgestellt das beim Editieren z.B. des Namens mit jedem Buchstaben das Query ausgelöst wird. Die Anzeige passt sich aber nicht immer an und man muss erst in ein anders Feld klicken. Bei jedem weiteren Klick in ein Feld wird wieder ein Query gemacht obwohl man nichts editiert hat. Da wäre es sicherlich hilfreicher eine Suchen Butten zu haben und ein Query nur anzustoßen wenn man fertig editiert hat. Siehe #185

[JohannMaierhofer]

Lösung #184 ist die Bessere