A
@Mechanics sagte in Denkansätze - Umgang mit Anwenderspezifisch formatierenden Daten; Laufzeit und DB-Abfragen...:
Ich weiß nicht, ob die Informationen so reichen, um das Problem umfassend zu verstehen. Vielleicht steh ich aber auch nur auf dem Schlauch.
Ausgehend von der Beschreibung hätte ich sowas wie Variante 2 gemacht. Ich meine, wenn du alle Informationen eh schon hast, dann kannst du doch eine optimierte Query bauen, unabhängig davon, wieviel Aufwand das wäre.
Die Daten habe ich den Ansatz noch nicht (wohl aber Daten die ich in einer Query übergeben kann um sie zu holen). Ich sträube mich bei einem kompletten Redesign alle Daten vorzuhalten und zu laden (sehr viel Netzwerkverkehr, manche unserer Kunden haben sehr langsame Verbindungen). Und überlege mir eine praktikable Alternative (zumal sich der bisheriege Cache der Anwendung zum Problemfaktor entwickelt hat).
Allerdings hört sich das "IDs besorgen"...
Das kam nicht von mir.
D.h., falls du die Query tatsächlich statisch (also, alles durch Joins oder temporäre Tabellen aufgelöst) aufbauen kannst, wüsste ich nicht, was dagegen spricht. Deine Bedenken wegen dem Variant Array beziehen sich auf die Laufzeit zum clientseitigen Verwalten der Daten? Glaube nicht, dass das ins Gewicht fällt, grad wenn es z.B. um std::variant und paar primitive Datentypen geht.
Diese Aussage hilft mir schon einmal weiter, dann scheint es auf Variante 2 hinauszulaufen.