Denkansätze - Umgang mit Anwenderspezifisch formatierenden Daten; Laufzeit und DB-Abfragen...

asc

Ich denke derzeit schon seit längeren über eine Aufgabenstellung nach, die zwar nicht aktuell umgesetzt werden muss, aber mir nicht ganz aus dem Kopf geht. Vielleicht hat jemand schon über ein Ähnliches Problem nachgedacht und eine Empfehlung zum Ansatz.

Ausgangspunkt ist eine Ausgabe von Terminen, die wiederum über zugeordnete Ressourcen etc. verfügen können. Der Anwender kann aktuell über fest vorgegebene Datenfelder die Ausgabe anpassen (dies wird als Vorlage gespeichert). Derzeit werden für die Ausgabe alle Termine die zu einer Grundbedingung (Zeitraum, ggf. eine Ressource oder Ressourcenart die enthalten sein muss...) die Daten zu jedem Termin vollständig eingelesen (Teilweise gecacht aber teilweise auch in der Abfrage) - egal ob benötigt oder nicht. Aus meiner Sicht ist und war das niemals optimal.

Da der gesamte Programmcode langfristig auf eine andere Plattform migriert und dabei auch das Konzept der Datenfelder überarbeitet werden soll, bin ich am überlegen wie ich am sinnvollsten das Einlesen aufbereiten mache.

Gegeben ist eine Vorlage, bei der die Datenfelder (wie auch immer) gegeben sind. Ich weiß über diese Datenfeldzuordnung auch welche Tabellen und Tabellenfelder auf DB-Seite benötigt werden. Ich sehe mehrere Varianten, da alles bislang nur in meinen Kopf durchgespielt ist, bin ich mir noch nicht ganz sicher ob ich mich nicht etwas verrenne und doch ein anderer Ansatz besser wäre. Meine aktuellen Überlegungen:

Ich mache einen ähnlichen Ansatz wie bisher, aber nur für die beteiligten Tabellen (hole aber für jede verwendete Tabelle alle Felder die überhaupt verwendet werden können). Dabei spare ich mir aber gegenüber den bisherigen Ansatz nur die nicht benötigten Tabellen (was aber durchaus einige sein können). Dafür kann ich aber auch einen OR-Mapper nutzen und vorgefertigte Datentypen.
Ich baue einen (oder mehrere) Selects dynamisch zusammen (ggf. "vorberechnet" einmalig beim Speichern der Vorlage - als View oder Text in der Vorlage) in dem wirklich nur die Tabellen und Felder verwendet werden die ich später auch brauche. Etwas aufwendiger in der Umsetzung, wobei eher die Datenhaltung (Variant-Array mit Einträgen je Feld? - oder hat jemand hier eine bessere Lösung?) ein Problem wäre. Anderseits lässt sich das Datenvolumen (das ggf. über das Netzwerk geht, wenn die Logik für die weitere Aufbearbeitung nicht auf dem Server läuft) stark begrenzen.

2.1 Mögliche Erweiterung: ich erzeuge schon beim Einlesen direkt die Strings die durch die Formatierung pro Datenfeld für die Ausgabe erzeugt werden (dadurch spare ich mir Variants, aber muss die gesamte Logik innerhalb des Einlesevorganges unterbringen).

Ich versuche bereits in den Select alle nötigen Aufbereitungen so unterzubringen, wie ich sie direkt in der Ausgabe benötige (kann aber abhängig von anderen Faktoren, wie z.B. ob anschließend html, csv etc. als Ausgabeart gewählt wird recht aufwendig sein [z.B. unterschiedliche Trennzeichen, Sonderzeichenbehandlung...]).

Von der Laufzeit her würde ich darauf tippen das ich mit 2 und 3 vermutlich am besten wäre, wobei ich bei 3 wohl auch recht schnell zu Fallbedingt nötigen Indexen kommen würde (was das ganze etwas aufwendiger macht).

Ich tendiere aktuell zu 2., aber würde gerne weitere Denkansätze, Ideen oder Verbesserungsvorschläge sammeln (schließlich hat man manchmal Scheuklappen auf, denkt zu komplex oder kommt in dem Moment einfach nicht auf bessere Ideen).

MaikHo

@asc sagte in Denkansätze - Umgang mit Anwenderspezifisch formatierenden Daten; Laufzeit und DB-Abfragen...:

Ich baue einen (oder mehrere) Selects dynamisch zusammen (ggf. "vorberechnet" einmalig beim Speichern der Vorlage - als View oder Text in der Vorlage) in dem wirklich nur die Tabellen und Felder verwendet werden die ich später auch brauche. Etwas aufwendiger in der Umsetzung, wobei eher die Datenhaltung (Variant-Array mit Einträgen je Feld? - oder hat jemand hier eine bessere Lösung?) ein Problem wäre. Anderseits lässt sich das Datenvolumen (das ggf. über das Netzwerk geht, wenn die Logik für die weitere Aufbearbeitung nicht auf dem Server läuft) stark begrenzen.

Diesen Weg würde ich teilweise auch gehen. Dazu kommt aber wie du deine DB aufbauen willst. Ich z.B haben immer eine Methode um "die" ID´s zu besorgen mit denen ich weiterarbeiten kann. Ansonsten habe ich select, update, delete Methoden die so aufgebaut sind das über den Parametern die Methode "weis" was erwartet wird.

Muß dazu sagen, in PHP ist das kein Problem für mich, nur als Anfänger in C++ noch etwas sehr holperich umzusetzen

asc

@MaikHo sagte in Denkansätze - Umgang mit Anwenderspezifisch formatierenden Daten; Laufzeit und DB-Abfragen...:

...Ich z.B haben immer eine Methode um "die" ID´s zu besorgen mit denen ich weiterarbeiten kann.

Ich versuche dies nach Möglichkeit in die Where-Klauseln der Selects oder notfalls als Übergabe als "User Table Type" (Join) einzubauen. Sprich: Möglichst nicht erst im Code filtern, erst recht keine Einzelselects abfeuern und auch auf "IN" im Select verzichten.

Mechanics

@asc sagte in Denkansätze - Umgang mit Anwenderspezifisch formatierenden Daten; Laufzeit und DB-Abfragen...:

Ausgangspunkt ist eine Ausgabe von Terminen, die wiederum über zugeordnete Ressourcen etc. verfügen können. Der Anwender kann aktuell über fest vorgegebene Datenfelder die Ausgabe anpassen (dies wird als Vorlage gespeichert). Derzeit werden für die Ausgabe alle Termine die zu einer Grundbedingung (Zeitraum, ggf. eine Ressource oder Ressourcenart die enthalten sein muss...) die Daten zu jedem Termin vollständig eingelesen (Teilweise gecacht aber teilweise auch in der Abfrage) - egal ob benötigt oder nicht.

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.

Allerdings hört sich das "IDs besorgen" für mich so an, als ob du nicht alle Informationen statisch hättest, und die erst als Ergebnis anderer Anfragen bereitstehen würden. Die Aussage kam zwar nicht von dir, aber du hast da auch nicht direkt widersprochen.

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.

asc

@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.