Array aus DB mit Zahlen füllen

[messie]

Moin,

bisher habe ich die Daten aus meiner DB einzeln ausgelesen. Also für jedes Einzeldatum ein FB-Zugriff. Das ist sehr zuverlässig aber auch sehr langsam.
Ich wollte mal fragen, welche Strategie für einen schnelleren Zugriff sinnvoll ist: die Verschachtelung von Befehlen statt des einzelnen Zugriffs (also statt des Zugriffs ein Anhängen von SQL-Sequenzen die dann in einem Schritt ausgelesen werden) oder eine SP die ein Array ausgibt? Zielvariable ist ein mehrdimensionales dynamisches Array.
Die erste Idee sieht auf den ersten Blick ziemlich fehleranfällig aus. Für die zweite Variante fehlt mir ein wenig der Ansatz.
Die Struktur ist Auftrag -> Fertigungslos -> Komponente -> Subkomponente -> Messwertarray
Die Daten gehören auf der Delphi-Seite also der Subkomponente.

Wie gehe ich das an, dass die Datenabfrage für die vorhandenen 300 Komponenten mit je 68 Subkomponenten (je 15 Messungen) nicht viele Minuten dauert?

Danke, Messie

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

[jobo]

Zitat von 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?

Ein Rutsch ist natürlich schnell, sagt das Wort ja schon.
Ich habe aber bereits nachgefragt, wie das Array bzw. das Mengengerüst ist. Wenn er eines Tages 10T Subcomponenten hat, macht Rutsch wahrscheinlich irgendwo halt.

Zitat von Furtbichler:

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

Natürlich, Du darfst hier alles, was die Forenregeln erlauben.
Um Dich vielleicht etwas zu beruhigen, was Du da schreibst hätte von mir sein können. Ich hab kein Problem mit SP. Es ist leider so, dass man auch hier häufig zu lesen bekommt, "ich mach das in einer SP, dann ist es schneller". Das stimmt halt so pauschal nicht. Eine SP die nichts anderes tut, als ein Selectstatement zu kapseln, bringt keinen nenneswerten Geschwindigkeitsvorteil. Erst unter gewissen Umständen, habe ich ja schon geschrieben.

Zitat von Furtbichler:

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)

Abgesehen von der fehlenden Programmierbarkeit, kann ich das ganze Interfacing auch mit Views erreichen. An einer guten SP will ich nichts optimieren, weiß nicht, wo Du das gelesen hast.

Zitat von Furtbichler:

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.

Ich aggregiere Daten in der Datenbank, verarbeiten tu ich sie erst Recht dort. Z.B. in Stored Procs
Selbst eine Weiterleitung mache ich gerne im Backend, also der DB per Link.

Komplette Abhängigkeit von der DB. Das klingt doch langsam etwas nach Sales BlaBla. Natürlich mache ich mich mit diesen und anderen Dingen abhängig von der Struktur. Deswegen gebe ich mir idR Mühe, eine performante und flexible Struktur zu schaffen.
Man kann das natürlich alles machen wie Du sagst, es muss nur am Ende jemand tun und bezahlen. In diesem Thread bswp. war jetzt nicht die Rede davon, die große, finale Anwendung zu schreiben. Ich hab schon 2 mal gefragt wo die Reise denn hingehen soll und mögliches Vorgehen skiziert.

Zitat von Furtbichler:

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

Dochdoch, ich verstehe das sehr gut. Die Tatsache, dass Du bei der möglichen Performancesteigerung "kann" schreibst, ist auch der einzige Haken an Deiner Liste. Habe ich ja oben schon erläutert. Ich muss nicht in die 3.Welt schauen, ich kann meine Anwendung auch per ISDN laufen lassen.
Eine SP ist nicht per se die beste Lösung. Eine schlechte clientseitige Implementierung wird nicht automatisch besser dadurch, dass ich auf die DBSeite wechsel. Das ist eigentlich alles, was ich sagen wollte. Erfahrungsgemäß lassen sich DB Anwendungen stellenweise bis zum Faktor 100, 1000, 10000 oder sogar unendlich tunen. Das ist keine Zauberei, sondern im Gegenteil recht einfach, wenn sie nämlich zuvor zum Stillstand gekommen sind.
Ursache ist bei großen Steigerungen allerdings meist eine ziemlich schlechte Erst-Implementierung.
Es gibt sehr naheliegende Dinge, die den Einsatz von SP empfehlenswert machen. Viele- auch hier- scheuen sich aber scheinbar davor.

Zitat von Furtbichler:

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.

Nachhaltig, ist wirklich ein tolles Wort, bzw. der Gedanke, der darin steckt. Es ist in Mode gekommen, als man versucht hat, den Leuten beizubringen, dass man mit klein klein jetzt nicht mehr weiter kommt und für die Umwelt und die Banken und überhaupt nun mal was ordentliches auf die Beine stellen muss. Und wir ahnen es alle, das kostet!
Also Deine Gedanken halte ich nicht für verkehrt, ich bezweifele nur, dass sie dem TE helfen.

[messie]

Moin und Danke erstmal für die Tipps. Hat ja ein wenig gedauert bis ich da wieder Zeit für habe.
Der Grund: der Import alter Daten dauert jetzt schon ein paar Wochen. Auch hier habe ich für jedes Fertigungslos, die Komponente und die Subkomponente sowie die Messdaten je einen Zugriff der sehr langsam ist. Hier kann ich auch nicht sicher sagen, ob ein Teil der Datensätze schon in der DB vorhanden ist und ich ein paar weitere Messdaten hinzu fügen muss (Die Messdaten sind oft in verschiedenen Dateien abgelegt).

Kann man das Beschreiben der Datenbank irgendwie beschleunigen?

Struktur ist:

Delphi-Quellcode:

 
      s := 'SELECT count(*) FROM ' + Fertigungslos + ' WHERE (Auftragsnummer = ' + QuotedStr(IntToStr(JobID)) + ' .... )';
      i := DM.IBCQuery1.FieldByName('COUNT').AsInteger;
      
      if i > 0 then
      begin
        //modify entry in table
        s := 'SELECT ID FROM ' + Fertigungslos + ' WHERE (Auftragsnummer = ' + QuotedStr(IntToStr(JobID)) + '....  )';
        if not DM.IBCQuery1.IsEmpty then
        begin
          idx := DM.IBCQuery1.fieldbyname('ID').AsInteger;
        end;
        s := 'UPDATE ' + Fertigungslos +, DRAWING_NO = .... 'WHERE ID = ' + IntToStr(idx);
        DM.IBCQuery1.SQL.Add(s);
        DM.IBCQuery1.ExecSQL;
        DM.IBCTransaction1.Commit;

      end
      else
      begin
        //add entry to table
        s := 'INSERT INTO ' + Fertigungslos + QuotedStr(Batch.DrawNo) + ....')';
        DM.IBCQuery1.SQL.Add(s);
        DM.IBCQuery1.ExecSQL;
        DM.IBCTransaction1.Commit;
      end;
      DM.IBCTransaction1.StartTransaction;
      DM.IBCQuery1.SQL.Clear;
      //Kontrolle
      s := 'SELECT ID FROM ' + Fertigungslos + ' WHERE (Auftragsnummer = ' + QuotedStr(IntToStr(JobID) .... ' )';
      DM.IBCQuery1.SQL.Add(s);
      DM.IBCQuery1.Open;
      if not DM.IBCQuery1.IsEmpty then
      begin
        idx := DM.IBCQuery1.fieldbyname('ID').AsInteger;
      end
      else
      begin
        Result := False;
        DM.IBCTransaction1.Commit;
        Exit;
      end;
      Batch.DBindex := idx;
      DM.IBCTransaction1.Commit;
      if SavePumps then
      begin
        for i := 0 to Fertigungslos.PumpCount -1 do
        begin
          //pumpen speichern
          SavePumpToDB(Fertigungslos.Items[i],idx);  ------> hier gehen die Strukturen iterativ weiter.
        end;
      end;
      Result := True;

Das blöde ist, ich brauche es nur ein Mal.

Grüße, Messie