Ich würde in deinem Beispiel, wenn es nicht möglich ist, die 7000 Datensätze um zwei "CacheFelder für NodeID und ParentID" zu erweitern und beim einlesen nach deiner komplexen Baumstrukturberechnung das Ergebnis dieser entweder direkt zurück in die
DB-Records geben, ober besser nach Berechnung eine JobTabelle als StrukturCache mit: Job(z.B. TimeStamp der Berechnung), RecordID(PK deines Datensatzes) und NodeID+ParentID anlegen. Ob nur im Speicher als wenn
SQL fähiges MemTable oder einfach in der
DB per Zusatztabelle(z.B. "TreeJobResult")
Dann behältst du dein "komplexes Struktur Konzept" so unverändert wie möglich bei, speicherst dir nur das Ergebnis deiner Berechnung(also die BaumStruktur) so minimalistisch wie möglich ohne Datenredundanz ab. Die
GUI greift bei Filtereinsatz einfach über die wieder nun
SQL fähig linearisierte SturkturInfo der Zwischenschicht auf die Ausgangsdaten zu.
Das ist bei 7000 Datensätzen sowohl vom Speicher als auch von der "zusätzlichen" Verarbeitungszeit pro Zugriff als auch beim pro Berechnung einmaligen erzeugen der "JobStruktur" völlig unkritisch.
(zufällig habe ich diese Schicht auch oft, denn das gleiche kann man mit den FilterErgebnissen so machen, so kann die
GUI dem Anwender ganz simpel erlauben, mal zurück zum vorherigen Filter zu gehen, ohne das der nochmal berechnet werden muss... mit dem simplen Konzept eines im Prinzip globalen CacheTimeStamps bekomme ich zwar keinen optimal reduziertes Nachberechnungsschema hin, aber es ist garantiert das ich nie mit eventuell alter CacheStruktur arbeite, notfals berechnen sich alle Filter eben bei nochmaliger Verwendung sauber neu)