Code zur Anzeige von Daten aus DataSet optimieren (Ausführung dauert zu lange)

DerSmurf schrieb:

Ich habe erstmal nur ein bisschen Code erstellt, um sicherzugehen, dass ich deine Vorgehensweise korrekt umgesetzt habe.

Naja, halb:

ErfinderDesRades schrieb:

Ich würde die Rekorde beim Einlesen des Datasets ausrechnen und merken.
Man kann innerhalb des Datasets ja zusätzlichen Code anlegen - auch Variablen, die die Rekorde merken.

Bei dir sind die Variablen,die die Rekorde merken, aber wieder im Form.
Wunderlich auch, dass deine DailyRecord-Variable vom Typ String ist.
Es geht doch um (Geld)Beträge, also um Zahlen.

Jo, so prinzipiell habichs so gemeint.
Nur wo ich angucke, scheint mir, was du an Rekorden speichern willst sind doch DailyIncome-Datensätze - dann speicher die doch auch (anstatt nur zweier ihrer Properties in je eine Variable).
Also sowas:Dann haste zwei Variablen gespart, und ausserdem Rekord-Datum und Rekord-Wert sinnig zusammengefasst - nämlich garnet erst auseinandergepflückt.
Wobei Benamung: Auf Englisch bedeutet "Record" glaub "Datensatz". Was "Rekord" auf englisch heisst weiss ich nicht.

Ich hab jetzt einen Dataset-Ordner gebastelt, und eine zusätzlcihe Dataset-Datei, weil das jetzt Business-Logik ist, und finde ich nicht gut, wenn solch im SolutionExplorer wie versteckt ist.
Dataset-Businesslogik gehört zusammen zum designeten Dataset, ist aber etwas anderes (und kann noch deutlich anwachsen) - daher es in zwei erkennbar getrennte Files aufteilen, und beide zusammen in einen Ordner - schaus dir mal an.
Weiters hab ich eine Version meiner Helpers zugefügt, weil ich eine meiner Linq-Erweiterungen benötigte.
Weil Standard-Linq ist unzureichend, wenn Maximum/Minimum-Datensätze gesucht werden.
Linq kann zwar ein Maximum auffinden in einer Datensatz-Menge, aber das ist dann nur eine dumme Zahl, und ist nicht der gesuchte Datensatz mit der Property, die den Wert aufweist.
Jo, mit meiner fabelhaften MaxBy-Extension kann ich deine Rekorde-Suche ziemlich schnucklig abfackeln:Du siehst - die Rekorde sind jetzt Rekord-Datensätze, nicht mehr nur die Rekord-Werte.
Ausserdem hab ich alle Rekorde in die Dataset-Klasse verfrachtet - also aus der DailyIncome-Tabelle rausgenommen, und aus der ProductRow-Klasse ebenfalls.
Die Rekorde nach Gruppen sind nun DistributionsRows, nämlich Zuordnungs-Datensätze, die auf beides verweisen: Auf die Rekord-DailyIncomeRow und auf die ProductGroupRow, für die das ein Income-Rekord ist.

Tatsächlich hätte man die Anlage der Rekorde auch so belassen können, wie du sie angelegt hast - in der DailyIncomeTable bzw. in den ProductGroupRows - wär sogar stärker objektorientiert.

Ist eine Gewohnheit von mir, da die Objektorientierung meist nicht so weit zu treiben.
Irgendwie isses bei meiner Version näher beieinander - nämlich alle Rekorde gleich welcher Art, und auch die Methode, die den Kram ausrechnet, stehen beieinander.
Bei deiner strengeren Objektorientierung ist das auf mehrere Klassen verteilt und wird dadurch unübersichtlicher.
Aber wie gesagt: das geht in Richtung Geschmackssache, bzw. kann von Fall zu Fall anders sein. Etwa wenn die BL an Umfang zunimmt, und dadurch wieder unüberichtlich wird, isses ja naheliegend, die BL weiter in die Klassen zu verteilen, und je Klasse eine Datei anlegen - OOP-Ordnung eben.

---

Achso - ich hab auch noch unnütze Bibliotheken rausgeworfen, sowie ein paar GeneralImporte

DerSmurf schrieb:

Was ich von diesem Ordner für das DataSet halten soll, weiß ich nicht - aber wenn man das so macht, mach ich das halt auch so.

Dass "man" das so macht wäre übertrieben.
Was man sagen kann "man macht" ist, dass man Businesslogik von Anzeige-Logik zu trennen versucht.
Also im Form Code zu haben, der iwelche Dataset-Tabellen durchsucht ist nicht sexy.
Solchen Code - Businesslogik - lagert man aus, und da gibts viele Möglichkeiten.
Ich finde meine Variante, die Businesslogik dann eben im Dataset anzulegen - da sie ja nicht ins Form gehört, besonders plausibel. Aber man kanns auch anders machen. Es ist sogar die Mehrheit die's anders macht, denn das typisierte Dataset ist den allermeisten Programmierern unbekannt.
Man kann die Businesslogik auch im Dataset versteckt lassen, dann sieht man sie nur bei Rechtsklick aufs Dataset, und "Code anzeigen". Aber Businesslogik ist total wichtig und ist imo eine sehr schlechte Idee, die dergestalt zu verstecken, dass sie nur per KontextMenü sichtbar wird.
Damit hast du also zwei Dateien im SolutionExplorer, und beide sind das Dataset - eben als partiale Klassen. Das habe ich durch den ähnlichen Datei-Namen kenntlich gemacht, dass die so eng zusammen gehören, und ausserdem durch den Ordner, wo beide eben drinne sind.
Im Fortschritt deines Projekt kann die BL auch noch gewaltig wachsen.
Wenn Ich Businesslogik in DataTables anlege (wie du's anfangs hattest - ist ja oft sehr sinnvoll), dann lege ich dafür oft weitere BL-Dateien an. Etwa eine DtsSettings.ProductGroup.vb käme bei raus, wenn ich inne ProductGroup Businesslogik von mehr als 20 Zeilen anzusiedeln hätte.
Dann hätten wir schon drei Dateien in dem Ordner - die alle dasselbe Dataset sind (partiale Klasse).

Also das ist auch was, was "man" macht: Man macht Zusammengehörigkeit von Dingen kenntlich, und möglichst leicht auffindbar.
Und wieder gibts dafür viele Mittel - in diesem Falle wende ich zwei Mittel an, nämlich die ähnliche Benamung der Dateien, und dass ich sie in denselben Ordner stopfe.
Und wieder machts die Mehrheit anders, denn auch partiale Klassen sind den meisten Programmierern kaum bekannt, sodass sie dieses Feature nicht aktiv zur Programm-Strukturierung nutzen.

---

DerSmurf schrieb:

Nach meinem Verständniss vom DataSet ist die Distribution_Table der Parent von DailyIncome und auch der Parent von ProductGroup.

nein - Distribution_Table ist den beiden anderen Tabellen untergeordnet - nicht über.
Das kannste direkt nachgucken im Dataset-Designer per Doppelklick auf die Relationen - da ist angegeben, was Parent- und was Child-Table ist.

Dein Code versucht iwie was anneres, als wie ich ProductGroupRecords gedacht hab.
Die Rekorde habe ich doch als Public ReadOnly ProductGroupRecords As List(Of Distribution_TableRow) bereitgestellt - die musst du durchschleifen - nicht die DtsSettings.ProductGroup.
Und jeder dieser Rekord-Datensätze - es sind ja Distribution_TableRows - hat eine Verbindung zu einer DailyIncomeRow, wo du das RekordIncome und das Datum abrufen kannst,
und eine Verbindung zu einer ProductGroupRow, wo du den Namen der ProductGroup abrufen kannst.

nee - ich glaub, meine Maximum-Suche ist fehlerhaft, es muss glaub heissen:Weil das Maximum der ProductGroupIncome-Werte wird ja gesucht, nicht dass der verknüpften DailyIncomes.
Glaub ich jedenfalls - ist nämlich auch ungetestet.

DerSmurf schrieb:

1. In der DtsSettings Klasse sind die drei Properties, welche die entsprechenden DataRows halten hinzugekommen:

VB.NET-Quellcode

1. Public IncomeRecord As DailyIncomeRow
2. Public CustomersRecord As DailyIncomeRow
3. Public ReadOnly ProductGroupRecords As New List(Of Distribution_TableRow)

Die List Of hast du ReadOnly deklariert, IncomeRecord und CustomersRecord nicht, obwohl hier ja eigentlich (erstmal) ein "nurLeseZugriff" auch reicht. Warum?

Readonly bewirkt, dass man die Variable nur bei der Deklaration beschreiben kann, oder spätestens im Konstruktor (= Sub New). Das scheidet für IncomeRecord und CustomersRecord ja aus, die können ja erst später berechnet werden, wenn Daten geladen sind.
Möglicherweise werden Daten ja auch mal neu geladen, also müssen diese Variablen auch mehrmals beschreibbar sein.
Aber die List(Of Distribution_TableRow) soll immer dieselbe bleiben.
Werden GroupRekorde berechnet, dann muss man die Liste nicht austauschen, sondern die Liste bleibt dieselbe, sie wird nur gelöscht und neu befüllt.
IncomeRecord und CustomersRecord sind ganz anfangs auch Nothing - die Liste hingegen ist gleich ein gültiges Objekt: eine leere Liste nämlich.

DerSmurf schrieb:

4.

ErfinderDesRades schrieb:

Dataset-Businesslogik gehört zusammen zum designeten Dataset, ist aber etwas anderes (und kann noch deutlich anwachsen) - daher es in zwei erkennbar getrennte Files aufteilen, und beide zusammen in einen Ordner

Ich nehme an das hat nur Einfluss auf das fertige Programm? - Also das was nach Projekt erstellen entsteht?
Dann macht es ja Sinn zusammengehöriges in eigene Unterordner zusammenzuschmeißen. Denn ich suche in meinem Hauptprogramm bei den ganzen Forms (alle im Hauptordner) schonmal öfters...

Wie du Ordner in deiner Solution einrichtest, und welche Dateien drinne sind ist ganz deine Sache.
Wenn du viele Forms hast ists sicher nützlich, die in einen Ordner "GUI" zu tun.
Man kann auch weiter strukturieren, etwa in Dialoge, Forms, UserControls unterteilen.
Bei mir gibts meist ein Mainform, ausserhalb aller Ordner. Darauf hab ich meist ein TabControl, und auf jedem Tab ein UserControl - die UserControls finden sich in einem Ordner "Ucl". Und dann habich noch Dialoge - "Dialogs".
Mehrere Forms habich meist nicht - ein MainForm mit Tabs ist mein bevorzugtes Anwendungs-Design.

DerSmurf schrieb:

5.

ErfinderDesRades schrieb:

Es ist sogar die Mehrheit die's anders macht, denn das typisierte Dataset ist den allermeisten Programmierern unbekannt.

Warum ist das so? Das typisierte DataSet hat doch im Vergleich zum untypisierten eigentlich nur Vorteile?

Ja, finde ich auch.
Aber man muss den Kram erstmal lernen, inklusive, es zu vermeiden, in untypisierten Code-Stil zurückzufallen.
Das ist für jmd, ders nicht anders kennt als untypisiert, quasi ausserhalb des sichtbaren Bereichs.
Und Microsoft publiziert nur Vorgehensweisen mit EF - Dataset würden die glaub am liebsten wieder abschaffen.

DerSmurf schrieb:

6. Ich nehme an das Kürzel BL steht für BusinessLogik? Und meint BusinessLogik Code der "rechnet" und "Daten sucht"? Also (fast) alles an Code, der nicht zur Anzeige dient`?
Im konkreten Beispiel hier wäre also das Zusammensuchen der Rekorde im DataSet Businesslogik, das Anzeigen dieser Daten dann nicht?
Und eben diese Businesslogik möchte ich (der Übersichtlichkeit halber) nicht in der Anzeigeform haben?

Ja genau.

Ich weiss nicht genau, welchen Code du meinst.
Wenn ich einen Code von dir überarbeiten soll, dann stell doch eine Version ein, die den unüberarbeiteten Code ohne viel schnickschnack-klickklick aufruft, und das Ergebnis auch anzeigt, vor allem, wenns schoma richtig ist.
Dann kann ich gleich mit überarbeiten anfangen, und muss nicht zuvor erstnoch alle möglichen Vorraussetzungen schaffen - die auch noch fehlerhaft sein können.

Jo, das ist schon bisserl knifflig.
Weil man muss die DistributionTableRows (was für ein abscheulicher Name!) erstmal nach Kategorien gruppieren.
Dann die einzelnen Kategorien-Gruppen nochmal nach Monaten gruppieren.
Und von den MonatsGruppen die Summen bilden.
Und von den Summen der Monatsgruppen die mit der maximalen Summe finden.
Und diese gefundenen Daten in ein Tuple stopfen, mit Monat, Kategorie und Summe.

Es gibt im Dataset.BL nun eine weitere Rekord-Liste - die Deklarationen sehen also nun so aus:

Zunächstmal: Die Gruppiererei geht noch ein bischen einfacher, denn die erste Gruppierung - die nach Kategorien - stellt das Dataset ja bereit - man kann von jeder ProductGroup ja die Distri-Dinger abrufen.
Dann wird die Methode so:
Das nur nebenbei

---

zu 1.
Das mit dem #If True ist ein Trick von mir, um Blockweises Auskommentieren zu ermöglichen.
Von dieser #If True - #ElseIf True - Kette wird ja nur der erste Block kompiliert.
so hab ich mehrere Varianten, und immer die oberste ist aktiv.
Ich kann auch im Editor mit der Maus einen anderen Block nach oben verschieben und so aktivieren.
Braucht man nur zum Entwickeln - habich vergessen zu löschen.

Zu 2.
Ich musste die Label-Creation der Monatsgruppen neu machen - das andere nicht.
Das andere hab ich auch garnet kapiert, und interessierte mich nicht - daher habichs in eine Methode gepackt, mit der ich mich nicht weiter auseinandersetzen musste.
Was ist das "Summe der Monatsrekorde"? - wird da wirklich der Monatsrekord von Kategorie1 - welcher vlt. aus Juni 2012 stammt mit dem Monatsrekord von Kategorie2- zB aus Dezember 2018 zusammengerechnet?
Was bringt das?

Zu 3.
Mit deine Label-Createrei will ich nix zu tun haben.
In meiner Welt sind diese Daten Tabellen, und gehören in einem Datagridview angezeigt.
Dynamisches Erzeugen von Controls führt ganz schnell in Sackgassen.
Etwa wenn Daten sich ändern muss man die entsprechenden Controls wieder-suchen um was neues reinzumachen.
Oder man muss alle Controls wieder runterschmeissen und erneut wieder hinmachen.
Und sortieren, editieren kann man sowas nicht.
usw.

zu 4.
Hmm - schwierig.
Ich glaub ich würde deutsch benamen.
ProductGroup -> Kategorie
DailyIncome -> Tag
Distribution_Table -> TagesUmsatz

Oder vielleicht auch nur Umsatz, denn dass es der Tages-Umsatz einer Kategorie ist, erschliesst sich aus den ForeignKeys: Einer geht auf Tag, der andere auf Kategorie.
Aber so Umbenennerei ist äusserst heikel.
Normal hilft der Background-Compiler ja, Codenamen umzunennen. Aber bei generiertem Dataset-Code kanner das nicht.
Tatsächlich fährt man am besten mit projektweiter Volltext-Ersetzung.
Aber schwierig - daher Backup machen, weil bestimmt mehrere Versuche nötig sein werden.

zu 5.
Jo - korrekt.
Du siehst: BusinessLogik hat einiges Wachstumspotential

zu 4.
Ja, gute Idee. Ist beim Coden echt doof das mit dem Unterstrich.
Andererseits wird genau diese Umbenennung die grössten Probleme machen.

DerSmurf schrieb:

Denn Date ist ja bereits von VB belegt, muss ich ja mit _date ansprechen.

Obwohl ich normalerweise grundsätzlich englische Namensgebung verwende, benutze ich bei Date aus diesen Gründen öfters den lateinischen Begriff ​Datum.
Das verstehen auch Nicht-Deutsche. Und Deutsche sowieso.