Update & Insert getrennt manuell ausführen oder eine Stored Procedure ?

[RWarnecke]

Hallo zusammen,

ich habe eine Tabelle mit 8 Spalten. Der Primary Key liegt auf Spalte 4. Jetzt muss ich in regelmäßigen Abständen neue Daten hinzufügen oder bestehende Daten updaten. Als erste Idee hatte ich, den befehl UPDATE OR INSERT zu nutzen. Da gibt es nur ein Problem, bei einem Update darf die Spalte 7 nicht verändert werden. Also fällt ja der Befehl UPDATE OR INSERT weg, nach meinen Wissensstand.

Als letzte Möglichkeit fällt mit nur noch eine Stored Procedure ein, die die entsprechenden Regeln verwaltet und dann das Update oder den Insert ausführt.

Habe ich jetzt noch eine Möglichkeit übersehen oder gibt es noch eine andere ? Oder gibt es für den Befehl UPDATE OR INSERT eine Option, wo ich eine Spalte weglassen oder hinzfügen kann ?

[Morphie]

Und bei "update or insert" hilft dir die Matching-Funktion nicht weiter?

Ist dein Primärschlüssel ein künstlicher Schlüssel? Hast du in einer anderen Spalte einen natürlichen Schlüssel, der den Datensatz ebenfalls identifiziert? (z.B. ArtikelNr)
Dann dürfte "Matching ArtikelNr" dir helfen

[EgonHugeist]

Schau da http://www.firebirdsql.org/refdocs/l...d21-merge.html mal rein.

Merge sollte beide Fälle deckeln.

[sx2008]

Wenn es nicht auf maximale Geschwindigkeit ankommt, dann kann man deine Anforderung sehr flexibel mit Delphi-Code lösen:

Delphi-Quellcode:

query.SQL.Tet := 'SELECT * FROM Tabelle WHERE keyfeld=:keyfeld';
query.parameters.ParamValues['keyfeld'] := ...; // muss ggf. an Zugriffskomponente angepasst werden
query.Open;
if query.IsEmpty then
begin
  // neuen Datensatz einfügen
  query.Append;
  // hier alle Felder beschreiben, die nur beim INSERT befüllt werden müssen
  query['keyfeld'] := ...;
  query['Spalte7'] := ...;
end
else
begin
  // bestehenden Datensatz ändern
  query.Edit;
  // hier alle Felder beschreiben, die nur beim UPDATE geändert werden müssen
  query['AnzahlModifikationen'] := query['AnzahlModifikationen'] + 1;
end;

// hier alle Felder befüllen, die sowohl beim INSERT als auch beim UPDATE geschrieben werden
query['Feld1'] := ...;
query['Feld2'] := ...;
query.Post; // Datensatz schreiben, im Hintergrund wird ein INSERT oder UPDATE generiert und abgeschickt

[RWarnecke]

Hallo zusammen,

danke für eure Antworten. Der Befehl MERGE sieht wirklich nachdem aus, womit ich beide Varianten abdecken kann. Ich werde das jetzt mal ausprobieren.

[Furtbichler]

Ich würde die Funktion in einer Stored Procedure kapseln, denn deine Business Logic besagt an der Stelle, das (zumindest) Spalte #7 nicht verändert werden darf.

Später kommen vielleicht noch mehr Regeln dazu, die vielleicht auch dazu führen, das man mit einem MERGE nicht mehr weiter kommt.

[EgonHugeist]

@Furtbichler,

ich persönlich nutze MERGE für FireBird oder das "ON DUPLICATED KEY" Event für MariaDB etc. relativ häufig. IMHO spricht nichts dagegen das beschriebene Problem in eine StoredProcedure zu kapseln. Dennoch würde ich auch dort auf MERGE zurückgreifen. Ich denke wir sind uns einig, alles soweit wie möglich weg vom Quellcode in Richtung DB zu schieben, um die Programm-Wartung an sich, so einfach wie möglich zu machen. Welche Alternative zu FB-MERGE würdest du hier vorschlagen, um beide Fälle von RWarnecke abzudecken? Eine SP zusätzlich könnte die Anzahl der Parameter im Quelltext selber mindern, bringt jedoch wieder einen zusätzlichen call mit sich. Ich bin der Meinung, dass MERGE in diesem Falle soweit optimiert, wie möglich funzt... Lieg ich denn da falsch?

[Furtbichler]

Zitat:

Zitat von EgonHugeist (Beitrag 1203772)

@Furtbichler,
Welche Alternative zu FB-MERGE würdest du hier vorschlagen, ...

Nein nein, Du siehst das völlig richtig: Solange MERGE den Job macht, ist die SP nichts anderes als ein Wrapper um das MERGE-Statement, aber man hat transparent die Möglichkeit hier an einer eventuell komplexeren Logik zu drehen, ohne die Anwendung anzufassen.

[EgonHugeist]

Handshake... :)