[MySQL] Update, Insert mehrere Tabellen InnoDB

Hi,

ich habe folgendes Problem. Ich habe ein HTML Form worin man meinetwegen eine Firma anlegen kann.
Diese Firma kann mehrere Kontakte und Adressen haben. Deswegen kann man in dem Form die Standard Adresse und Kontakt anlegen. Jetzt schicke ich das gesamte Form per Ajax (serialize) an PHP. Dort muss das ja einmal in der Firmen Tabelle angelegt werden und dann der Kontakt in die Firmen_Kontakt Tabelle sowie die Adresse in die Firmen_Adressen Tabelle.
So und da weiß ich nicht weiter, denn wenn ich drei INSERT's mache kann es ja sein, das die Firma noch eingetragen wird aber die Adresse z.B. nicht. Ok hier habe ich das jetzt so gelößt das ich die Firma im Fehlerfall wieder lösche. Ob das so gut ist? Und vorallem wie ist das bei dem Update da kann ich zwar mehrere Tabellen in einem Query updaten aber erstens funktioniert das nicht so ganz und zweitens will ich ja noch den Mitarbeiter der diese Firma updatet, auch in eine seperate Tabelle eintragen. Da eine Firma ja mehrmals geupdatet werden kann. Hier hätte ich ja jetzt ein Update und Insert, aber was ist wenn das Update ok ist aber der Insert nicht? So was wie Rollback gibt es bei InnoDB ja nicht.

Ich hoffe ich konnte mein Problem einigermaßen schildern. Und hoffe auf Hilfe!
 
So und da weiß ich nicht weiter, denn wenn ich drei INSERT's mache kann es ja sein, das die Firma noch eingetragen wird aber die Adresse z.B. nicht.
Die Frage ist also, wenn irgendwas danebengeht, wie man die gesamte DB konsistent haltet.
Ok hier habe ich das jetzt so gelößt das ich die Firma im Fehlerfall wieder lösche.
Und wie? Wenn "irgendwas" danebengeht könnte das PHP-Script auch grad in der MItte abgebrochen sein, aus
irgendeinem Grund. Die Inserts auf Erfolg prüfen hilft nicht viel. Siehe "Transactions" (begin, commit, rollback...),
um zusammengehörende Anweisungen möglichst ganz oder gar nicht auszuführen.

So was wie Rollback gibt es bei InnoDB ja nicht.
Doch: http://dev.mysql.com/doc/refman/5.0/en/innodb-implicit-commit.html usw.
 
Danke Dir erstmal.

Die Frage ist also, wenn irgendwas danebengeht, wie man die gesamte DB konsistent haltet.

Ja genau ich möchte, da es ja zusammenhänge sind, dass wenn was daneben geht nichts eingetragen oder geupdatet wird.

Und wie? Wenn "irgendwas" danebengeht könnte das PHP-Script auch grad in der MItte abgebrochen sein, aus
irgendeinem Grund. Die Inserts auf Erfolg prüfen hilft nicht viel. Siehe "Transactions" (begin, commit, rollback...),
um zusammengehörende Anweisungen möglichst ganz oder gar nicht auszuführen.

Ok das leuchtet mir ein. Habes es halt so gemacht 1.INSERT Status OK dann 2.INSERT wenn hier ein Fehler lösche 1.INSERT.


lese ich mir mal durch.
 
Ok das leuchtet mir ein. Habes es halt so gemacht 1.INSERT Status OK dann 2.INSERT wenn hier ein Fehler lösche 1.INSERT.

Genauso macht man es im produktiven Umfeld eigentlich nicht. Überlege dir, was in deinem Fall eine Transaktion ist. Besteht eine Transaktion möglicherweise aus mehreren Datenbankoperationen, machst du um alle eine begin => commit/rollback.

Wenn du eine anständige Infrastruktur aufbaust, und bspw. mit Exceptions arbeitest, kannst du im catch-Block die Transaktion zurück rollen. Ein guter Ausgangspunkt ist sowas:

Code:
try
{
  connectDB();
  executeDB(Statement1);
  executeDB(Statement2);

  commitDB();
}
catch(Exception ex)
{
  logException(ex);
  rollbackDB();
}

Wenn eine Operation einen Fehler verursacht und eine Exception wirft, wird sofort der catch-Block ausgeführt. Wie man sieht, wird erstmal geloggt und anschließend ein Rollback gemacht. Du kannst es auch vertauschen, das Logging sollte atomar und fehlerfrei sein, bzw. keine weiteren Fehler werfen.
 
Überleg dir mal folgenden Ansatz:
Anstatt die Logik in PHP abzuarbeiten, kann man das auch mit Stored Procedures kapseln. Vom Frontend her ist es nämlich ein einziger Prozess: erfasse/erstelle eine Firma. Diese hat in deinem Fall 3 Unteraufgaben. Nun kannst du von PHP her eine Stored Procedure aufrufen, die innerhalb einer Transaktion all diese 3 Schritte nacheinander abarbeitet und im Fehlerfall Meldungen zurück ans Frontend liefert.
 
Danke erstmal für eure Hilfe
Nur bin ich da leider ein bisschen durcheinander gekommen. Natürlich gibt es bei InnoDB 'Rollback'...... Das funktioniert auch.
Aber eigentlich soll die DB auf MyIsam aufgebaut werden oder besser gesagt Sie ist es zur Zeit. Und ich bin mir nicht schlüssig ob
ich nicht auf InnoDB umbaue. Das Problem wäre damit ja behoben.
Nur wie komme ich auf eine Lösung welchen DB Typ ich nehm. Den die SELECT, INSERT, UPDATE Anweisungen halten sich eigentlich in Waage.
Die größte Tabelle hat um die 300000 Einträge.

Überleg dir mal folgenden Ansatz:
Anstatt die Logik in PHP abzuarbeiten, kann man das auch mit Stored Procedures kapseln. Vom Frontend her ist es nämlich ein einziger Prozess: erfasse/erstelle eine Firma. Diese hat in deinem Fall 3 Unteraufgaben. Nun kannst du von PHP her eine Stored Procedure aufrufen, die innerhalb einer Transaktion all diese 3 Schritte nacheinander abarbeitet und im Fehlerfall Meldungen zurück ans Frontend liefert.

Wie du wahrscheinlich rausließt, bin ich kein gelernter Programmierer. Ich bin aber sehr daran interessiert das sehr strukturiert und prof. aufzubauen. Deshalb bin ich sehr dankbar für solche Anregungen.
Ich achte schon daruf HTML, PHP, JS usw. strikt zu trennen. Nur bin ich in der Objektorientierten Programmierung sowie für das MVC Konzept nicht oder noch nicht weit genug um das so aufzubauen.
Deshalb mach ich das immoment noch prozedural, was natürlich meinen Ansatz es prof. zu machen wiederspricht... :)
 
Also stellt sich nun die Frage InnoDB vs MyISAM? Dazu gibt es bereits viele gute Links die dir helfen können. Grundsätzlich kommt es darauf an wie du die DB verwenden willst.
http://stackoverflow.com/questions/12614541/whats-the-difference-between-myisam-and-innodb
http://stackoverflow.com/questions/20148/myisam-versus-innodb
http://www.percona.com/blog/2009/01/12/should-you-move-from-myisam-to-innodb/

Bezüglich Stored Procedures, das ist ein möglicher Weg um das zu implementieren. Es gibt auch andere und dabei hat jeder seine Vor- und Nachteile. Du hast hier im DB Subforum gepostet, stellst du die selbe Frage im PHP Subforum wirst du bestimmt auch andere Vorschläge hören. Was aber auch mit entscheiden sollte welchen Weg du gehen willst betrifft deine eigenen Skills. Wenn du dich z.B. x mal besser mit PHP als mit DB's auskennst, ist es wohl effizienter es da zu lösen.
 

Neue Beiträge

Zurück