Array aus DB mit Zahlen füllen

[Furtbichler]

Wie sieht denn deine Tabellen- bzw Datenbankstruktur aus? Generell geht es am einfachsten und am schnellsten mit einem schnöden

Code:

select * from Messwerte

[messie]

Die Messswerte liegen in der DB als freie Abkömmlinge der Subkomponente und haben noch einen Zeitstempel als Zusatzinformation.

Im Moment hole ich mir das Fertigungslos, die Komponente und die Subkomponente einzeln. Die Messwerte werden auch einzeln geholt und ins Array gelegt.

Ein get * from Messwerte where diese und jenes? Mal ausprobieren

Grüße, Messie

[jobo]

Wenn Du innerhalb Deiner Anwendung wahlfreien Zugriff auf die Messwerte von 300x68 Subcomponenten benötigst, ist es evtl. sinnvoll, diese in einem Rutsch in ein entsprechend dimensioniertes Array einzulesen.
Ausgangspunkt wäre eine(!) Abfrage über alle Entitäten, die Dein Array hält, deren Daten dann iterativ ins Array übertragen werden.
Das wäre das Vorgehen, bei dem das Array Verfahren wohl erhalten bleiben könnte- wenn notwendig / gewünscht.

Frage wäre, wie sich das Volumen perspektivisch entwickelt und ob man an diesem Verfahren festhalten kann /muss.
Was spricht gegen eine gezielte Datenabfrage und Haltung in Datasets ohne Verwendung eines Arrays und die dazu notwendige Datenübertragung ins Array?

[Furtbichler]

Ich würde mir eine stored proc schreiben, die mir zu einem Auftrag/Los alle notwendigen Informationen abholt. Das ist dann eine einzige Abfrage.

Die Messwerte holst du dir dann mit 'select * from Messwerte where SubComponentID = :SubComponentID'

[messie]

Moin,

Zitat von Furtbichler:

Ich würde mir eine stored proc schreiben, die mir zu einem Auftrag/Los alle notwendigen Informationen abholt. Das ist dann eine einzige Abfrage.

Ich denke mal, das ist ein Ansatz der gut passt.

Zitat von jobo:

(...) evtl. sinnvoll, diese in einem Rutsch in ein entsprechend dimensioniertes Array einzulesen.

Das entsprechende Array gibt es schon. Es wurde vorher aus Textdateien gefüttert. Sieht also so aus als könnte das der richtige Ansatz sein.

Für Stichworte/Tipps/Links in Richtung Umsetzung wäre ich dankbar.

Grüße, Messie

[jobo]

Also ein Rutsch, das macht es wohl schneller, aber nicht besser und nicht "nachhaltig" - tolles Wort!
Dieser Vorschlag macht nur Sinn, wenn Du große Teile Deiner Anwendung (das Array und alles was dran hängt) so erhalten willst oder musst wegen des sonst bevorstehenden Änderungsaufwands.

Ich wiederhole also meine Frage, muss alles gleichzeitig im Zugriff sein?
Muss es im Array sein?
Was spricht gegen die einzelne Abfrage der benötigten Daten und deren verbleib im Dataset- ohne Array? Das sind für eine Subkomponente 1x68*15 Zeilen? Wären im Zugriff vielleicht ne 10tel Sekunde?!

Wie war noch mal die Mengenentwicklung?

Zur StoredProc:
Das kann man machen, bringt aber m.E. im Vergleich zu Select nur etwas, wenn mglw. ein komplexes Select Statement durch Procedure Sprachkonstrukte vereinfacht werden kann. Es garantiert darüber hinaus eine ordentliche Parametrierung und Vorkompilierung.
Lohnt sich vor allem bei hochfrequenter Nutzung, viele User, die ständig zugreifen.

[Furtbichler]

Zitat von jobo:

Also ein Rutsch, das macht es wohl schneller, aber nicht besser und nicht "nachhaltig" - tolles Wort!

Hä? Wieso nicht? Was ist an 'nachhaltig' als Wort bemerkenswert?

Wieso ist 'schneller' (hier) nicht 'besser'?

Wenn man die Daten in einem `SELECT` abholen kann, um sie in ein Array zu packen (wenn man es braucht), was soll daran nicht nachhaltig sein?

Bezüglich der Nachhaltigkeit bzw. dem 'Änderungsaufwand' (falls ich das für dich übersetzen darf): Die Daten werden an einer(!) Stelle in der DB erzeugt (Stored Procedure) und an einer(!) Stelle in der Anwendung empfangen und umgeformt (aka ins Array geschrieben).

Selbst wenn man die komplette DB umschreibt, muss man für diesen Ansatz nur die Stored Procedure anpassen. Und selbst wenn man die Datenstruktur in der Anwendung komplett neu schreibt, muss man widerum nur eine Stelle anpassen (die SP).

Bin mal gespannt, was Du hier optimieren willst. (bin ja immer offen für Verbesserungen)

Zitat von jobo:

Was spricht gegen die einzelne Abfrage der benötigten Daten und deren verbleib im Dataset- ohne Array?

Wenn Du die Daten im Dataset lässt (und die Daten direkt aus der DB holst) machst Du deine Anwendung komplett(!) abhängig vom konkreten DB-Design: Ein Horrorszenario in komplexen Anwendungen.
Weiterhin: Will man die Daten anzeigen, aggregieren, weiterleiten, weiterverarbeiten etc. sollte man das schnellstmöglich aus dem Dataset holen. Etwas langsameres als ein Dataset fällt mir jedenfalls auf Anhieb nicht ein. Will man die Daten dagegen eh nur in seiner zusammengeklicken Oberfläche anzeigen (Chart o.ä.) dann kann man das so machen, also auf das Array verzichten. Aber so programmiert man heute eigentlich nur noch im LOB-Bereich, bei dem man die kleinen Frickeltools raushauen muss. Dafür ist Delphi ja geeignet.

Zitat:

Zur StoredProc:
Das kann man machen, bringt aber m.E. im Vergleich zu Select nur ...

Du hast das nicht verstanden:

• Eine SP abstrahiert den Zugriff auf die Datenbank (Nachhaltigkeit bei Änderungen in der DB)
• Eine SP verbirgt das konkrete DB-Design. Ich kann hier Daten aus unterschiedlichen Tabellen zusammensuchen, die sich so nicht verknüpfen (JOIN) lassen. (Drastische Vereinfachung und Verbergen eines schlechten DB-Designs).
• Eine SP kann die Geschwindigkeit drastisch erhöhen: Wir schreiben gerade Anwendungen für die dritte Welt, bei der man mit Netzwerken um die 256kBit (shared auf 600 Clients) auskommen muss. Aber auch in Gigabit-Netzen zahlt sich jede gespaarte Anfrage aus: Eine SP kann auch mehrere Resultsets liefern (eine Batchanweisung natürlich auch).

Es sind also nicht nur performancetechnische Betrachtungen im Grenzbereich anzustellen, sondern auch Vereinfachungen und Nachhaltigkeit (schon wieder dieses Wort ) bei der Softwareentwicklung, -weiterentwicklung, -anpassung und -wartung. Gleiches gilt für die DB. Ich muss offen für Erweiterungen sein: Eine Abstraktionsebene im DB-Layer(Views und SPs zum Laden und SPs und updateable Views zum Speichern) vereinfachen hier den Entwicklungsaufwand um den Faktor 5 und höher. Demgegenüber stehen jedoch zeitkritische Operationen, wo ich u.U. direkt mit den Daten reden muss (bulk updates z.B.). Hier muss man im Einzelfall entscheiden, inwieweit man die Anwendung abhängig vom konkreten Design machen muss.