docs: archive completed refactoring notes

Move old refactoring task files to erledigt/ archive.

Co-authored-by: CommandCodeBot <noreply@commandcode.ai>

refactorings/erledigt/actions_splitten.txt

@@ -0,0 +1,8 @@
+Aufteilung von rw_actions.hpp in einzelne Dateien in einen separaten Verzeichnis. 
+Vorteile:
+ - Übersichtlicher, leichter handhabbare Klassen
+ - Strukturelle Verbesserung
+ - Verringerung von Abhängigkeiten
+ 
+ 
+

refactorings/erledigt/boost_flyweight.txt

@@ -0,0 +1,8 @@
+Verwendung von boost::flyweight<> in Klasse AV_Config um Speicherbedarf zu senken. 
+Das macht insbesondere für KHF-Daten Sinn da diese im Vorwege als VQ_Data (AV_Config) im Speicher
+gehalten werden. boost::flyweight<> kann hier redundante Keys von AV_Config effizienter speichern.
+
+Stand:
+    Abgearbeitet!
+    Die Idee wurde spezialisiert mittels boost::unordered_map umgesetzt.
+

refactorings/erledigt/datecalc.txt

@@ -0,0 +1,4 @@
+Das Modul "datecalc" soll unter Berücksichtigung der Performanz durch die Boost-Bibliothek "Date time" ersetzt/ realisiert werden.
+Da "Date time" nicht Header-Only ist, müssen die boost-libs generiert und in der Referenz Umgebung bereit gestellt werden.
+
+

refactorings/erledigt/intmenge.txt

@@ -0,0 +1,6 @@
+Die Klasse IntMenge soll die Klasse Bitset ersetzen. 
+Vorteile sind:
+- Effizienz
+- Kein Verstoß gegen GPL
+- Sauberer Source-Code
+

refactorings/erledigt/komprimierte_paketdaten.txt

@@ -0,0 +1,23 @@
+Komprimierung von Paketdaten
+
+Hintergrund:
+im Host-RW werden alle Daten eines Pakets im Vorwege der Beregelung eingelesen. Dem Speicherbedarf steht auf der anderen
+Seite ein performantes Auslesen der Daten aus der DB und ein effizienter Zugriff auf die zwischengespeicherten Daten gegenüber.
+
+Das Refactoring besteht in der Komprimierung der zwischengespeicherten Daten, welche einen Schein bzw. einen BHF zugeordnet sind.
+Beispiele sind alle Leistungen, Kennzeichen, Regeländerungen zu einen Schein oder alle Kennzeichen zu einen BHF.
+
+Erwarteter Gewinn: Erste Tests mit der freien ZLib-Bibliothek lassen eine signifikante Komprimierungsrate (30-60 % Leistungen) realistisch erscheinen.
+Bei großen Pakete kann das einige 100 MB ausmachen.
+
+Bemerkungen zur Realisierung:
+Die Umsetzung erfüllt die Erwartungen knapp. Anstatt der 30 - 60% Einsparung hat sich eine Einsparung von ca. 25-40% ergeben.
+Die Ursache liegt hierfür in der Organisation der Paketdaten. Diese werden pro Tabelle zur jeweiligen ID gruppiert. Diese Gruppen
+werden dann für lohnende Tabellen komprimiert. ZZ sind dies vor die Leistungen(Gruppe hier zu Schein), Regeländerungen (Schein), 
+Kennzeichen zur Tätigkeit (BHF Oder Schein). Die Kompromierung ist besonders dann effektiv, wenn eine ausreichend große
+Datenmenge vorliegt. Gibt es pro Gruppe wenig Daten (KS_KRANKENSCHEN ein Schein pro Gruppe, ...) so die theorische Ausbeute 
+klein und ein geswisse Overhead muß zudem kompensiert werden. Daher lohnt ein Komprimierung i.d.R. nicht.
+Die Beschränkung auf wenige Tabellen hat allerdings den Vorteil die Ladezeit der Daten kaum zu verlängern.
+
+
+

refactorings/erledigt/le_speicher_bedarf.txt

@@ -0,0 +1,15 @@
+Zustand: abgearbeitet mit Überarbeitung XML-Klassen
+
+der Platzbedarf der Überweiserdaten soll reduziert werden.
+
+Speicher ohne Überweiser-Daten
+-> Prozess nutzt 39 MB
+
+Speicher mit Überweiser-Daten
+  1 :RW:18:55:32:Prozess nutzt 603 MB
+  
+  5 :RW:18:55:06:Tabelle 'LE_BTYPNR_QPT' 80507 Saetze gelesen.
+  5 :RW:18:55:23:Tabelle 'LE_BTYPNR_QPLT' 90514 Saetze gelesen.
+
+
+

refactorings/erledigt/leer_menge.txt

@@ -0,0 +1,26 @@
+Folgerungen aus der Eigenschaft LEER(menge)
+
+Wie in der LB zur AG02965 beschrieben, ist für das Erfülltsein der Eigenschaft LEER(menge) vereinbart, 
+dass menge = {} gilt. Im Source gibt es die ausgezeichnete Menge C_MENGE_LEER, welche als einzige das
+Prädikat LEER() erfüllt (Analogie ist NULL in Datenbanken). ZZ. führen Mengenoperationen mit der Menge
+C_MENGE_LEER aufgrund unterschiedlicher Grundgesamtheiten zu Fehlern.
+
+Das Refactoring soll die Mengen-Operationen mit der C_MENGE_LEER nach obiger Vereinbarung
+ermöglichen:
+
+enthaltensein:      x in C_MENGE_LEER => false (sollte bereits funktionieren)
+Element hinzufügen: C_MENGE_LEER + {x} -> C_MENGE_LEER
+
+vereinigung:        C_MENGE_LEER + Menge = Menge + C_MENGE_LEER = Menge
+differenz:          Menge - C_MENGE_LEER = Menge, C_MENGE_LEER - Menge = {}
+schnitt:            C_MENGE_LEER * Menge = Menge * C_MENGE_LEER = {}
+
+Mengenfunktionen werden zZ im Modul mtools und in der Klasse Menge bereitgestellt. Hier sollte die
+Funktionalität in der Klasse Menge zusammengefasst werden und die Methoden um die Berücksichtigung
+der Menge C_MENGE_LEER erweitert werden.
+
+
+
+
+
+

refactorings/erledigt/redundante_includes.txt

@@ -0,0 +1,7 @@
+Unnötige Include's entfernen.
+
+Vorteile:
+ - Redundate Abhängigkeiten entfallen
+ - Strukturverbesserung
+ 
+Das CQM Tool Cast soll diese Aufgabe vereinfachen! 

refactorings/erledigt/sb_meth_splitten.txt

@@ -0,0 +1,6 @@
+Aufteilung von sb_meth.* in einzelne Dateien in einen separaten Verzeichnis. 
+Vorteile:
+ - Übersichtlicher, leichter handhabbar
+ - Strukturelle Verbesserung
+ 
+ 

refactorings/erledigt/ur_meth_spitten.txt

@@ -0,0 +1,6 @@
+Aufteilung von ur_meth.* in einzelne Dateien in einen separaten Verzeichnis. 
+Vorteile:
+ - Übersichtlicher, leichter handhabbar
+ - Strukturelle Verbesserung
+ 
+ 

refactorings/erledigt/xml_ranges.txt

@@ -0,0 +1,9 @@
+Stand: Umgesetzt
+
+Anstelle von Kopieraktionen sollen STL-konforme Bereiche in den XML-Text verwendet werden.
+
+Vorteile sind:
+- geringerer Speicherbedarf
+- erhöhte Effizienz
+
+Anpassung ist bereits in Arbeit und in den Modulen rw_smallxml.* in Refactoring-Ordner enthalten.