SQL "Update or Insert" langsam

[p80286]

Zitat von BlueStarHH:

A VarChar(50) PK
B VarChar(50) PK
C Blob Text 80

Muss ich das SQL also anpassen?

Zwei Primary Keys? und dann augenscheinlich Text?
Da bin ich auf den ersten Ärger mit Umlauten und/oder Codepages gespannt.

Gruß
K-H

[DeddyH]

2 PKs geht nicht, aber ein zusammengesetzter über 2 Felder schon

[jobo]

Zitat von p80286:

Zitat von BlueStarHH:

A VarChar(50) PK
B VarChar(50) PK
C Blob Text 80

Zwei Primary Keys? und dann augenscheinlich Text?
Da bin ich auf den ersten Ärger mit Umlauten und/oder Codepages gespannt.

Zitat von DeddyH:

2 PKs geht nicht, aber ein zusammengesetzter über 2 Felder schon

Ja, ein Schlüssel kann aus mehreren Feldern bestehen.
Am interessantesten finde ich aber ein BLOB Text(80), der in das "Upsert" involviert ist.
Wie sieht es da mit Indizierung aus? Und wenn vorhanden, greift sie?

Wenn nicht, was ich mir ganz gut vorstellen kann, bedeutet jedes einzelne "Upsert" ein Fullscan. Das dann in einer Schleife und die Performance ist im A..

[user0815]

Zugriff erfolgt über: IBDAC
kurz mal geguckt: https://www.devart.com/ibdac/docs/?batchops.htm

Batch INSERT operation sample
Let’s try to insert 1000 rows to the BATCH_TEST table using a Batch Insert operation:

Delphi-Quellcode:

var
  i: Integer;
begin
  // describe the SQL query
  IBCQuery1.SQL.Text := 'INSERT INTO BATCH_TEST VALUES (:ID, :F_INTEGER, :F_FLOAT, :F_STRING, :F_DATE)';

  // define the parameter types passed to the query :
  IBCQuery1.Params[0].DataType := ftInteger;
  IBCQuery1.Params[1].DataType := ftInteger;
  IBCQuery1.Params[2].DataType := ftFloat;
  IBCQuery1.Params[3].DataType := ftString;
  IBCQuery1.Params[4].DataType := ftDateTime;

  // specify the array dimension:
  IBCQuery1.Params.ValueCount := 1000;

  // populate the array with parameter values:
  for i := 0 to IBCQuery1.Params.ValueCount - 1 do 
  begin
    IBCQuery1.Params[0][i].AsInteger := i + 1;
    IBCQuery1.Params[1][i].AsInteger := i + 2000 + 1;
    IBCQuery1.Params[2][i].AsFloat := (i + 1) / 12;
    IBCQuery1.Params[3][i].AsString := 'Values ' + IntToStr(i + 1);
    IBCQuery1.Params[4][i].AsDateTime := Now;
  end;

  // insert 1000 rows into the BATCH_TEST table
  IBCQuery1.Execute(1000);
end;

[bnreimer42]

Da kapselt dann aber IBDAC die Batch-Operation.
Das gibt es bei Firebird keine direkte Unterstützung in der API.

Gruß

Björn

[jobo]

Zitat von bnreimer42:

Da kapselt dann aber IBDAC die Batch-Operation.
Das gibt es bei Firebird keine direkte Unterstützung in der API.

Meinst Du eine Batchkomponente?
Mittels Transaktionshandling sollte es eigentlich wurscht sein, was an Spezialitäten da ist.
Wenn man eine Reihe von Befehlen absetzt, werden sie erst mit "Commit" commited.
Viele Commits, nach jedem insert bspw, bringen auch eine Verzögerung. Blockweise commit sind schneller, ist aber glaub ich marginal.

[bnreimer42]

Zitat von jobo:

Meinst Du eine Batchkomponente?
Mittels Transaktionshandling sollte es eigentlich wurscht sein, was an Spezialitäten da ist.
Wenn man eine Reihe von Befehlen absetzt, werden sie erst mit "Commit" commited.
Viele Commits, nach jedem insert bspw, bringen auch eine Verzögerung. Blockweise commit sind schneller, ist aber glaub ich marginal.

Ja, die Batchkomponenten kann ja nicht zaubern.
Firebird kann zum Beispiel nicht die "Indexpflege" erst beim Commit machen und damit nur einmal für alle Commits.

Es kann auch sein, dass viele Statements im Batch langsamer sind. Wenn eine weitere ältere Transaktion alte Versionen der Sätze noch im Fokus hat, muss der Server neue Pages allozieren um die neuen Versionen der Sätze zu speichern. Beim Insert ist es klar, dass er das immer machen muss, aber bei mehreren Updates kann er die alten Speicherbereiche recyceln.

Das wird bei größeren Satzlängen problematischer, also insbesondere beim Updaten von größeren BLOBs, die ja dann ggf. auf eigene Pages pro BLOB ausgelagert werden zusätzlich zu den Pages, die er beschreiben muss, um den Satz zu speichern.

Diese Phänomene können obigen Geschwindigkeitsvorteil wieder wett machen.

Natürlich gibt es aber Gründe für eine derartige Implementierung und das ist die Datensicherheit und den Erhalt der Konsistenz der Datenbankdatei zu jedem Zeitpunkt. Bei Datenbanken sollte immer die Datensicherheit höher bewertet werden, als die Schnelligkeit.



Gruß

Björn