Schnellste Insert Möglichkeit für eine DB?

[Stevie]

Das Problem bei deinem Beispiel oben ist, dass es dort keine Möglichkeit gibt, zu parametrisieren, da du die komplette Tabelle selektierst.
Das Statement, was du selbst als tödlich bezeichnest, ist ein Kandidat dafür.

[p80286]

Mir scheint wir schreiben aneinander vorbei.

Code:

sqltext:='select adresse from tabelle1 where vorname='+form1.edit1.text+';'

sollte (darf)darf nicht genutzt werden

richtig wäre dies hier:

Code:

sqltext:='select adresse from tabelle1 where vorname=:prmvorname ;'

Gleiches gilt für die Übergabe aus Listboxen u ä.
also statt

Code:

sqltext:='select adresse from tabelle1 where vorname='+Listbox1.items[listbox1.selected]+';'

dies

Code:

sqltext:='select adresse from tabelle1 where vorname=:prmvorname ;'

Aber wie geht man mit folgender Situation um (stark vereinfacht):

Code:

select tabtyp from Tabelle1; 

case tabtyp of 
  Akte1 : sqltext:= 'select info from Tabelle2'; 
  Akte2 : sqltext:= 'select info from Tabelle3'; 
  Akte3 : sqltext:= 'select info1 from Tabelle4,Tabelle5 where Tabelle4.xid=Tabelle5.txid'; 
usw.

Aus einer Abfrage ergibt sich ein Wert, der die folgende Abfrage bestimmt. (z.B. die Tabelle)

Gruß
K-H

[moelski]

Moin !

Hulla, habe das We hier nicht rein gesehen und nun entstehen hier fast Grundsatzdiskussionen :)

Ich möchte aber nochmal auf den Kern meines Problems zurück kommen.
Mein Beispiel ganz zu Anfang:

Delphi-Quellcode:

for I := 1 to Amount do begin 
    Inc(Counter); 
    DBQuery.SQL.Text := 'INSERT Into ' + Table + ' (ID, PROP01, PROP02, PROP03, PROP04, PROP05, PROP06, PROP07, PROP08, PROP09, PROP10) VALUES (:wert1, :wert2, :wert3, :wert4, :wert5, :wert6, :wert7, :wert8, :wert9, :wert10, :wert11);'; 
    DBQuery.Prepare; 
    DBQuery.Params[0].AsInteger := Counter; 
    DBQuery.Params[1].AsFloat := Random(10000); 
    ...
    DBQuery.Params[10].AsFloat := Random(10000); 
    DBQuery.ExecSQL; 
  end;

... war auch nur ein Beispiel und trifft nicht den Kern meines Problems.

Die For Schleife dient hier ja nur zum Erzeugen von Last. In Wirklichkeit aber kommen die Daten bei uns von Geräten. Die Geräte senden (um es einfach zu machen) Spannung, Strom, Ladung. Und das mehr oder minder schnell.

Wir haben also nicht einen Block an Daten den ich auf einen Schlag wegschreiben möchte (was man dann ja über eine Transaktion könnte), sondern wir haben eher eine stetige Datenmenge die permanent weggeschrieben werden muss.

Ich sehe da im Moment zwei Varianten:
1) Man schreibt jeden Datensatz sofort bei Erscheinen in die DB. Das (so verstehe ich das hier) erzeugt aber eine Menge Overhead.
2) Ich könnte Datensätze erst puffern und dann z.B. immer 10 Datensätze mittels Transaktion wegschreiben. Das würde den Overhead auf der DB verringern, aber mehr Aufwand am Client bedeuten.

Wie seht ihr das?

[exilant]

Zitat:

Zitat von moelski

Moin !

Ich sehe da im Moment zwei Varianten:
1) Man schreibt jeden Datensatz sofort bei Erscheinen in die DB. Das (so verstehe ich das hier) erzeugt aber eine Menge Overhead.
2) Ich könnte Datensätze erst puffern und dann z.B. immer 10 Datensätze mittels Transaktion wegschreiben. Das würde den Overhead auf der DB verringern, aber mehr Aufwand am Client bedeuten.

Wie seht ihr das?

Wir erfassen hier ebenfalls in einer 24/7 Umgebung große Mengen von Messwerten. Es hat sich bewährt, die Daten lokal zu puffern und dann
blockweise in die DB zu schreiben. Wie die Pufferung aussieht richtet sich danach, welche Zeitverzögerung Du Dir erlauben kannst.
Ich puffere hier Blöcke von 3 Min. bis zu 1 Stunde.
Die Daten werden lokal in CSV Dateien geschrieben und dann nach Zeitraum X and den Server übertragen (FTP mit den Indys). Der schreibt dann diese Daten in _EINER_ Transaktion in die DB (Firebird). Es handelt sich dabei dann um einige hundert bis zu ettlichen tausend "inserts". Das geht granatenschnell und läuft hier sehr zuverlässig.
Direkt in die Datenbank werden nur die Daten geschrieben, deren Überwachung kritisch ist. Das erledigen die entsprechenden Clients dann selber.

[moelski]

Moin !

Zitat:

Die Daten werden lokal in CSV Dateien geschrieben und dann nach Zeitraum X and den Server übertragen

Das fällt bei uns schon mal raus, denn wir nutzen an der Stelle die Embedded Version und keinen Server.

Aber gut, dann würde man die Daten sammeln und in einem eigenen Thread nach x Sekunden / Minuten / ... in die DB schieben.

[p80286]

Zitat:

Zitat von moelski

Aber gut, dann würde man die Daten sammeln und in einem eigenen Thread nach x Sekunden / Minuten / ... in die DB schieben.

Dem ist eigentlich nichts hinzuzufügen, nur eine kleine Anmerkung:
jedes Insert/Update ist von einer Transaktion "umhüllt". Je größer die Datenmenge innerhalb der Transaktion, desto größer der Verwaltungsaufwand pro Transaktion (Rollback) darum würde ich die Menge nicht ins "unendliche" wachsen lassen.

Gruß
K-H

[moelski]

Moin !

Zitat:

Je größer die Datenmenge innerhalb der Transaktion, desto größer der Verwaltungsaufwand pro Transaktion (Rollback)

Hmm aber hat nicht jemand ein paar Postings vorher gesagt das man sowas gerade in Transaktionen Hüllen sollte? Widerspricht sich das nicht ein bisschen?

Zitat:

darum würde ich die Menge nicht ins "unendliche" wachsen lassen

Was wäre denn ein verträgliches Mass?

[p80286]

nocheinmal
Jedes INSERT/UPDATE-Statement steckt in einer Transaktion (Naja so sollte es eigentlich sein).
Und bei einigen Systemen hast Du es in der Hand wann die Transaktion mit Commit/Autocommit abgeschlossen wird.

Wie exilant schrieb:

Zitat:

Das geht granatenschnell und läuft hier sehr zuverlässig.

Ist natürlich von der Umgebung und der Datenmenge abhängig. Ggf. solltest Du das mal ausprobieren wie Dein System darauf reagiert.

Eine Faustformel wie "1000 Datensätze und dann ab damit" halte ich für nicht sehr vernünftig.
Ich rechne immer mit "die Transaktion ist abgeschlossen" die Daten sind gespeichert. Wenn Du die Daten in einer Datei zwischenspeicherst, dann ist das ja nicht ganz so wichtig.
(Wieso kann man Deine Meßwerte eigentlich nicht in einer Datei zwischenspeichern? ob server oder embedded hat doch damit nichts zu tun. Oder gibt's da ein Problem mit dem Plattenplatz????)

Gruß
K-H

[exilant]

Zitat:

Zitat von moelski

Moin !
Was wäre denn ein verträgliches Mass?

Ich habe manchmal 8.000 und mehr "inserts" in einer Transaktion. Das hat noch nie zu Problemen geführt.
Das ist dank Firebirds MGA auch kein sooo wahnsinniger Overhead für die DB. Da würde ich mir keine Sorgen machen.
Und wie ich schon sagte: Es ist schnell.

Delphi-Quellcode:

insertstatement.transaction.starttransaction;

try
  readcsv;
  while not eof(csv)do begin
    insertstatement.paramby.... := ...csv_value....
    insertstatement.paramby.... := ...csv_value....
    insertstatement.paramby.... := ...csv_value....
    ...
    insertstatement.execute;
    readcsv;
  end;
  insertstatement.transaction.commit;
  killcsv;
except
  on e:exception do begin
    insertstatement.transaction.rollback;
    WhateverYouMustDo;
  end;
end;

[xZise]

Moin,
ich habe dazu mal eine Frage, weil mir fällt da das Einlesen einer Schülerliste ein. Das heißt ich habe eine Datenbank mit Personen und dann bekomme ich eine neue Liste mit Personen. Jetzt will ich neue Personen hinzufügen, und alte (also die nicht in der neuen Liste stehen) löschen. Aber ich will nicht die komplette Liste neu anlegen.

Nun ist das aktuell so, dass jeder ein Flag bekommt, ob er in der Liste ist und standard ist das keiner. Dann geht er jede Person auf der Liste durch und vergleicht das mit der Datenbankliste und setzt das Flag auf „vorhanden“. Wenn das nicht der Fall ist, wird die Person hinzufügt. Kann ich jetzt zu Anfang ein SQL Befehl erstellen (präventiv) und das dann nutzen, auch wenn zwischenzeitlich mal ein Update kommt?
Ich benutze SQLite, und hoffe mal, dass ich nicht geschlagen werde, dass ich keinen neuen Thread auf mache :)

MfG
Fabian