Mein Ansatz wäre im Prinzip ähnlich dem von Stahli gerade vorgeschlagenem, das mit getrennten Dictionarys zu lösen... und ganz wichtig: eine eigene CompareFunktion, weil man so einfach selbst bestimmt was wie verglichen werden soll... das ist zu 99% viel passender wie ein "zwangsweise 100% binary egual" ArrayVergleich per Operator durch den Compiler
- also alles zunächst wie gewollt im erste "LiveDictionary" zufügen bzw. aktualisieren
- dann z.B. im Timer alles(per "for each") aus dem "LiveDictionary" im ersten "LiveDictionary" auf Vorhandensein prüfen und wenn ja aktualisieren bzw. sonst zufügen und passendes auslösen
- usw...
Das mit dummen Arrays zu machen ist uneffektiv. Dictionarys mit dummen Records wären da sicher schonmal etwas besser und eleganter. Wenn es "schön" werden soll, das das Ganze mit/in eigener Storage-Klasse kapseln und dort auch die zugehörigen internen Comparer mit unterbringen... Mr. Rabe würde gleich noch ein ZugriffsInterface und ein SpeicherInterface designen, dann wird es sogar nebenbei universell erweiterbar/austauschbar.
Auch bei QuickAndDirty würde ich bei uns mindestens ne Kombi aus einer eineindeutigen "globalen/gesamt" TObjectList(oder "="
DB-Tabelle) UND separaten Dictionarys[HASH->"ol"INDEX](oder "="
DB-Zuordnungstabellen) für deine verschiedenen (Zeit)Kategorien und/oder States aller Störungen realsieren und das in einer eindeutig benannten Klasse(hier z.B. "Störungen") kapseln.
Dies entspricht der Tatsache, das dein Problem bei uns unter dem allgemeinem Sichwort "JobList" liefe und per "DesignRule" nach diesem allgemeingültigen internem Grundkonzept gelöst werden würde.