Datenbank Insert verhindern oder Datensatz löschen

Computer: Software & Programmierung Datenbanken allgemein
#1

Hallo zusammen,

ich habe da mal ein Problem. Datenbank ist MySQL. Ich habe zwei Tabellen: „orig“ und „copy“. Ein Datensatz soll normalerweise in beide Tabellen geschrieben werden. Dazu existiert ein Trigger, der alle neuen Datensätze, die in „orig“ eingefügt werden, automatisch nach „copy“ kopiert werden. Das funktioniert prima. Nun zu dem Problem: wenn in einem Datensatz ein bestimmtes Feld den Inhalt „1“ hat, dann soll der Datensatz zwar in die Tabelle „copy“ kopiert werden, allerdings am Besten gar nicht erst in der Tabelle „orig“ auftauchen. Die Inserts gehen allerdings alle auf die „orig“ Tabelle. Hat jemand eine Idee, wie man das lösen kann?

Vielen Dank und beste Grüße!

#2

Moin, Wolfgang,

wenn in einem Datensatz ein bestimmtes Feld den Inhalt „1“ hat,
dann soll der Datensatz zwar in die Tabelle „copy“ kopiert werden,
allerdings am Besten gar nicht erst in der Tabelle „orig“ auftauchen.

ent oder weder! Das triggernde Ereignis heißt doch „Insert into orig“, oder? Somit wird erst getriggert, wenn orig inserted ist.

Was hält Dich davon ab, die Abfrage und das Löschen gleich mit in die Trigger-Routine zu packen? Ob das geht, weiß ich jetzt nicht; wenn Auslöser und Trigger als LUW (Paket, das für den Rollback zusammengehört) gesehen werden, dann wohl eher nicht.

Andere Möglichkeit: Den Eingabebestand vorher trennen und zwei Routinen zum Einfügen aufbauen: Eine arbeitet wie bisher, die zweite inserted nur in copy.

Gruß Ralf

#3

Guten Tag,

Hallo Ralf,

danke für’s Feedback! Ja, das triggernde Ereignis heißt Insert into Orig. Es gibt da 2 Möglichkeiten: before insert und after insert. Beide gestatten es aber nicht, den insert nicht durchzuführen. Leider geht es auch nicht, die Abfrage und das Löschen gleich mit in die Trigger-Routine zu packen. Und last but not least geht die letzte Alternative auch nicht, da wir seitens des Inserts Begrenzungen haben :frowning:…
Grüße, Wolfgang

#4

Hi Wolfgang,

Dein Vorhaben erinnert mich an den Fallschirmspringer, der unbedingt einen Palstek in die Reißleine springen wollte :smile:

Wenn Dinge mit Bordmitteln nicht zu lösen sind, dann deutet das meist auf einen Entwurfsfehler hin. Vielleicht solltest Du den Kunden mal fragen, was er unter Original und Copy verstehen will, wenn plötzlich das Copy größer sein darf als das Original. Stichwort: Lifecycle.

Gruß Ralf

#5

Hi,
habe mangels DB nicht ausprobiert ob das geht:
was ist wenn du in der „copy“ Tabelle auch einen Insert-Trigger implementierst der den Rekord dann aus der „Orig“ löschst?

Gruss
Joey

#6

Hi Joey,

hatte ich bereits ausprobiert … geht leider auch nicht …

Grüße,

Wolfgang

#7

Hi Ralf,

ja, ich denke du hast Recht :wink: … Wir werden das wohl irgendwie anders lösen müssen…

Grüße,

Wolfgang

#8

Moin, Joey,

was ist wenn du in der „copy“ Tabelle auch einen
Insert-Trigger implementierst der den Rekord dann aus der
„Orig“ löschst?

sowas darf eigentlich nicht gehen, weil der Insert und der Trigger vom DBMS in einer Transaktion zusammengefasst werden. Klappt der Trigger nicht, aus welchen Gründen auch immer, dann wird auch der Insert nicht comitted bzw. ein Rollback aufgesetzt. Idee dahinter: Entweder geht alles durch oder gar nichts.

Gruß Ralf

#9

Hi Ralf,

sowas darf eigentlich nicht gehen, weil der Insert und der
Trigger vom DBMS in einer Transaktion zusammengefasst werden.
Klappt der Trigger nicht, aus welchen Gründen auch immer, dann
wird auch der Insert nicht comitted bzw. ein Rollback
aufgesetzt. Idee dahinter: Entweder geht alles durch oder gar
nichts.

wenn es denn ein Tabellentyp ist, der Transaktionen unterstützt.
Was bei MySQL nur die InnoDB und die BerkeleyDB sind.

Daher bin ich mir nicht sicher, ob es bei einer MyISAM Tabelle gehen würde. (Wenn es auch sehr hässlich wäre)

Gruss
Joey

#10

wenn es denn ein Tabellentyp ist, der Transaktionen
unterstützt.
Was bei MySQL nur die InnoDB und die BerkeleyDB sind.

das ist aber keine echte transaktion , sie wird nur so ausgeführt wie eine . Ich denk es macht alles virtuell und wenn alles ok, dann schreibt es , wenn nicht , schreibt es garnichts und löscht sein virtuellen zwischenspeicher.

Daher bin ich mir nicht sicher, ob es bei einer MyISAM Tabelle
gehen würde. (Wenn es auch sehr hässlich wäre)

Gruss
Joey

#11

Hi Joey,

wenn es denn ein Tabellentyp ist, der Transaktionen
unterstützt.

beim 3. Lesen endlich verstanden:

wenn es denn ein DBMS ist, das Transaktionen unterstützt.

Daher bin ich mir nicht sicher, ob es bei einer MyISAM Tabelle
gehen würde. (Wenn es auch sehr hässlich wäre)

Trigger ohne Transaktionskonzept (oder von mir aus LOW - Logical Unit of Work) ist sinnlos.

Gruß Ralf

#12

wenn es denn ein Tabellentyp ist, der Transaktionen
unterstützt.
Was bei MySQL nur die InnoDB und die BerkeleyDB sind.

das ist aber keine echte transaktion , sie wird nur so
ausgeführt wie eine . Ich denk es macht alles virtuell und
wenn alles ok, dann schreibt es , wenn nicht , schreibt es
garnichts und löscht sein virtuellen zwischenspeicher.

Was sind denn unechte Transaktionen?
Wie die Transaktionen physisch ausgeführt werden ist dem Entwickler i.d.R. egal.
Einige Datenbanken führen eine extra Datei als Transaktionslog, andere benutzen interne Verweise.
Hauptsache sie können alle Aktionen wieder rückgängig machen, falls es kein COMMIT gibt.

#13

Was sind denn unechte Transaktionen?

Eine wo ich kein commit , rollback … senden muss kann oder darf .
Es also für den user keine transaktion ist.
Zumal Trigger auch bei nicht transkations tabellen fromat funktionieren.

Bzw erklär du mir was in deinem sinne der Befehl tranksaktion ist und was der Befehl Trigger bei den MyISAM bzw InnoDB macht.

Bei MyIsam wird die Transaktion atoma durchgeführt , mit lock tables nachgestellt etc .
Bei InnoDB wird es wirklich über die gesammte transaktion organisiert und nicht atoma abgearbeitet.
Das sind sehr grosse unterschiede , sonst könnte man auch ohne crash ganz einfach MyIsam mit transaktionen füttern , diese hat aber kein journal in diesem sinne .

#14

Habe ich so undeutlich geschrieben? Genau das habe ich mit meinen vorigen Postings gemeint. Daher sollte der OP eben mal probieren ob es mit den Triggern nicht doch geht wenn er einen NICHT transaktionsfähigen Tabellentyp wie zb. MyISAM nimmt …