PHP Frage, Denkfehler für eine SQL Aktualisierung mit Versionierung

[ayngush]

Welchen Vorteil in der Usability bringt Dein Vorschlag?

Das habe ich doch schon mehrfach erwähnt: Der Vorteil ist ein Protokolldatensatz pro Aktion pro Entität. Das ist der Sinn eines audit trails. Die Aktion zeitlich zu protokollieren.

Warum sollte man die Alt-Daten indizieren wollen?
Indiziert wird die ZuordnungsID und die AktionsID und die UserID, sodass man den entsprechenden Protokollausschnitt bei einer bestimmten Person / eines bestimmten Datensatz / eines Users / einer Aktionskategorie referenzieren kann.
Die Alt-Daten zu indizieren ergibt für mich gar keinen Sinn, da darauf weder gesucht noch abgefragt wird - die stehen nur für ein Frontend-Tool zur Verfügung, damit das alte Daten darstellen und auf Knopfdruck den alten Zustand wiederherstellen kann.

Wenn du übrigens alle verwendeten "Spalten", also auch die DatenAlt und DatenNeu, indizierst drückst Du sogar noch mehr auf die Performancebremse.
Oder meinst Du der Index baut sich ohne Systemressourcen beim Einfügen zusammen? Das anstrengenste für ein RDBMS sind Transaktionsfeste DML Statements, insbesondere, wenn dort viele Indizes, vor allem "precompilierte" (Oracle Materialized Views aber das sind Sonderfälle z.B.) dranhängen. Indizieren würde ich an der Stelle ausschließlich numerische Indentifikatoren, sonst frisst dein Protokollieren locker die Hälfte der Gesamtperformance beim Einfügen / Ändern / Löschen. Das kann nicht Sinn der Übung sein.

MySQL ist halt ein sehr einfaches DBMS mit einer eher geringen Performance, das nicht sehr gut mit der Hardware skaliert und eher schlechte Recovery Möglichkeiten bietet (je nach Storage Engine fehlen dann entweder wichtige Features oder das Gesamtkunstwerk hat wieder andere Einschränkungen).
Wenn es "die Engine" für CRMs wäre, warum verwenden die großen CRMs und ERPs dann kein MySQL, sondern PostgreSQL oder gar teure bis sehr teure DBMS wie MS SQL Server, SAP und Oracle?
Aber sorry, diese Diskussion können wir gerne woanders führen, die gehört hier absolut nicht hin.
Gründe dafür: Eventuell meine Qualifikation? Gut, die kennst Du jetzt nicht, kannst Du aber gerne per PN erfragen.

PS: Trigger haben mit "Vergleichen" an sich zunächst überhaupt nichts zu tun.

 

[Andreas_]

Das habe ich doch schon mehrfach erwähnt: Der Vorteil ist ein Protokolldatensatz pro Aktion pro Entität. Das ist der Sinn eines audit trails. Die Aktion zeitlich zu protokollieren.

Es erschließt sich mir nicht, worin der Vorteil eines Protokolldatensatzes liegen soll, wenn mir dies die Auswertung des audit trails erschwert. Wie ich schon geschrieben habe, ein derartiger JSON-BLOB bietet nur einen Vorteil, wenn es eine Software gibt, die den BLOB schreiben und lesen kann. Wenn Du Dir die Postings des TE durchliest, weißt Du aber, dass es eine derartige Software nicht gibt.

Zum Monitoring einer Tätigkeit kann es erforderlich sein zu recherchieren, wie viele Änderungen durch einen Mitarbeiter in einem bestimmten Zeitraum erfolgen. Mit einem JSON-BLOB, der keine direkten Rückschlüsse auf die bearbeiteten Datenfelder zulässt, ein extrem aufwendiges Unterfangen.

Auch ist mit dem JSON-BLOB bei häufig geänderten Datensätzen nur sehr aufwendig festzustellen, welcher Mitarbeiter eine bestimmte Änderung vollzogen hat.

Warum sollte man die Alt-Daten indizieren wollen?

Keine Ahnung - ich würde es nicht tun. Ich würde aber indizieren wollen, welche Datenfelder geändert wurden.

Wenn du übrigens alle verwendeten "Spalten", also auch die DatenAlt und DatenNeu, indizierst drückst Du sogar noch mehr auf die Performancebremse.
Oder meinst Du der Index baut sich ohne Systemressourcen beim Einfügen zusammen? Das anstrengenste für ein RDBMS sind Transaktionsfeste DML Statements, insbesondere, wenn dort viele Indizes, vor allem "precompilierte" (Oracle Materialized Views aber das sind Sonderfälle z.B.) dranhängen. Indizieren würde ich an der Stelle ausschließlich numerische Indentifikatoren, sonst frisst dein Protokollieren locker die Hälfte der Gesamtperformance beim Einfügen / Ändern / Löschen. Das kann nicht Sinn der Übung sein.

Derartige Indizes sind für die Idee nicht erforderlich und ich sehe auch keinen Grund dazu. Da die typische Suche nach Kunde, Zeitraum und geänderten Datenfeld oder alternativ nach Mitarbeiter recherchieren dürfte, würde ich andere als die dafür benötigten Felder auch nicht indizieren. Keine Ahnung woher Deine Phantasien stammen.

MySQL ist halt ein sehr einfaches DBMS mit einer eher geringen Performance, das nicht sehr gut mit der Hardware skaliert und eher schlechte Recovery Möglichkeiten bietet (je nach Storage Engine fehlen dann entweder wichtige Features oder das Gesamtkunstwerk hat wieder andere Einschränkungen).

Ich glaube Du bist da nicht auf dem aktuellen Stand. Es gibt mittlerweile sowohl Hochverfügbarkeitslösungen als auch Clusterlösungen für eine hohe Skalierbarkeit. Nicht umsonst unterstützen Oracle wie auch Amazon und neuerdings sogar Microsoft mit Azure auf MySQL basierende Cloud-Lösungen.

Wenn es "die Engine" für CRMs wäre, warum verwenden die großen CRMs und ERPs dann kein MySQL, sondern PostgreSQL oder gar teure bis sehr teure DBMS wie MS SQL Server, SAP und Oracle?

Eine Vielzahl der OpenSource-CRM unterstützt MySQL. MySQL ist sicherlich keine eierlegende Wollmichsau und auch nicht "die Engine" für CRM, aber MySQL deckt alle grundlegenden Funktionalitäten ab, die ein CRM benötigt. Aber es war vermutlich auch zuviel erwartet, von Dir tatsächlich Gründe zu lesen, die gegen einen Einsatz von MySQL bei einem CRM sprechen.

Ich bin sicher kein MySQL-"Fan", beruflich hatte ich bisher nur mit Oracle und MS SQL zu tun, aber ich sehe keinen Grund MySQL zu verteufeln.

 

[Domi83]

Moin moin, ich habe die Unterhaltung gestern schon verfolgt, war dann aber etwas verwirrt Also 1., 2. und 3. Normalform ist mir auch noch ein Begriff, ich verwende auch gerne die 2. oder 3. Normalform, wobei es auch Tabellen gibt wo ich noch keinen Grund für eine Trennung sehe und ganz zu Anfang in der 1. Normalform fast alles in einer Tabelle sammle, bis ich merke "hey, das wird zu viel" und es dann splitte.

Wenn Du Dir die Postings des TE durchliest, weißt Du aber, dass es eine derartige Software nicht gibt.

Was diesen Satz angeht, es handelt sich im allgemeinen um ein Webbasiertes System und dahinter steckt (jetzt nicht hauen) ein MySQL System (MariaDB Server). Ich weiß das im Bereich Web-Programmierung auch oft PostgreSQL verwendet wird, damit hab ich mich aber noch nie auseinander gesetzt.

Liegt unter anderem daran, dass ich nicht weiß wie die Syntax in den Systemen sind und wie gravierend die Unterschiede dann sind. Vorteile und Nachteile hatte ich mir auch schon ganz oft durch gelesen, hab dann aber am Ende immer wieder entschieden das MySQL ausreichend wäre.

Bezüglich den Triggern zum loggen was / wie / wo passiert, habe ich mir die Beispiele schon mal angeschaut, ich versuche das mal auf meine Bedürfnisse zu produzieren und sehe dann was passiert. Falls die Frage aufkommt, was ich hier eigentlich mache... meine Kollegen und ich haben eine Buchungsmaske für Versicherungen aufgebaut. Einer von euch Spezialisten mit (vermutlich) einem Studium, hat da bestimmt zig Ideen für Verbesserungen etc. aber das was wir hier haben funktioniert seit Jahren sehr gut und ohne Probleme.

Aktuelles Szenario ist, dass jemand unser System haben möchte, wir dieses aber in diesem Durchgang gleich optimieren wollen (wenn wir schon intensiv daran arbeiten). Wir sind alle drei gelernte IT'ler, aber keiner von uns ist jetzt ein studierter der mit Fachbegriffen um sich wirft, falls mir also der eine oder andere Fachbegriff nicht auf der Zunge liegt, liegt es nicht daran das ich das "Feature" oder die Funktion nicht kenne, sondern nur das ich den Fachbegriff nicht kenne Liegt unter anderem aber auch daran, dass ich primär mit Kunden zu tun habe die davon keine Ahnung haben und ich mir die Angewohnheit gemacht habe sie nicht mit Fachbegriffen zu nerven. Daher wollte ich mich im Vorfeld entschuldigen, wenn ich mit dem einen oder anderen Wort dann nichts mehr anfangen kann

Gruß, Domi

 

[ayngush]

Es erschließt sich mir nicht, worin der Vorteil eines Protokolldatensatzes liegen soll, wenn mir dies die Auswertung des audit trails erschwert. Wie ich schon geschrieben habe, ein derartiger JSON-BLOB bietet nur einen Vorteil, wenn es eine Software gibt, die den BLOB schreiben und lesen kann. Wenn Du Dir die Postings des TE durchliest, weißt Du aber, dass es eine derartige Software nicht gibt.

Sie wollen doch gerade so eine Software bauen?! Darum geht es doch hier...

Zum Monitoring einer Tätigkeit kann es erforderlich sein zu recherchieren, wie viele Änderungen durch einen Mitarbeiter in einem bestimmten Zeitraum erfolgen. Mit einem JSON-BLOB, der keine direkten Rückschlüsse auf die bearbeiteten Datenfelder zulässt, ein extrem aufwendiges Unterfangen.

Erm... Schau Dir doch mein Posting nochmal an. Du kannst genau feststellen, ohne den JSON-String (der übrigens auf einen MS SQL Server erst ab 8kb als Objekt angelegt wird) anzuschauen / zu referenzieren / auszuwerten, abzufragen oder sonst wie zu berücksichtigen, Wer, Wann, Was auf welcher Entität gemacht hat. Ich kann Dir genau sagen, welcher Mitarbeiter wann einen Kontakt geändert hat. Ich kann Dir genau sagen, welcher Mitarbeiter am meisten gelöscht hat. Ich kann Dir genau sagen, an welchen Wochentag / zu welcher Uhrzeit wie viele Änderungen vorgenommen werden usw. Und das alles ohne den JSON Anteil zu parsen, der für einen ganz anderen Zweck vorhanden ist.

Nur wenn es darum geht die neuen Daten mit den alten Daten zu VERGLEICHEN oder die alten Daten (eines bestimmten Zeitpunktes / zum Zeitpunkt der Löschung) wieder herzustellen (was nicht mehr Teil eines audit trails ist aber eine Anforderung bei uns war, um Vandalismus / Fehleingaben auf der Schnittstelle nachträglich, punktuell rückgängig zu machen) muss der JSON-Anteil angeschaut werden und ja, dafür braucht man dann ein spezielles Tool, welches man sich bauen muss, ist ja auch logisch...

Auch ist mit dem JSON-BLOB bei häufig geänderten Datensätzen nur sehr aufwendig festzustellen, welcher Mitarbeiter eine bestimmte Änderung vollzogen hat.

Wieso? Ich glaube Du hast mein System nicht verstanden. Wir verwenden es ja produktiv, von daher kann ich dir sagen: Nein, ist es nicht... Alle notwendingen Informationen sind ja vorhanden, auf den JSON-Datenfeld muss zu keiner Zeit irgendetwas referenziert werden. Oben habe ich es ja noch mal etwas ausführlicher erklärt.
Wie man in deinen System übrigens so etwas wie Datensatz angelegt / Datensatz gelöscht unterbringt ist mir bis heute noch ein Rätsel. Geht da noch mal ans Whiteboard

Ich glaube Du bist da nicht auf dem aktuellen Stand. Es gibt mittlerweile sowohl Hochverfügbarkeitslösungen als auch Clusterlösungen für eine hohe Skalierbarkeit. Nicht umsonst unterstützen Oracle wie auch Amazon und neuerdings sogar Microsoft mit Azure auf MySQL basierende Cloud-Lösungen.

Das macht ein DBMS noch lange nicht performant. Cloud Computing kann alles mögliche virtualisieren. Dennoch skaliert die Engine nicht so gut, weswegen es für spezielle Anwendungsbereiche ja auch andere Lösungen gibt. Siehe die ganzen objektorientierten Datenbanken...

Eine Vielzahl der OpenSource-CRM unterstützt MySQL. MySQL ist sicherlich keine eierlegende Wollmichsau und auch nicht "die Engine" für CRM, aber MySQL deckt alle grundlegenden Funktionalitäten ab, die ein CRM benötigt. Aber es war vermutlich auch zuviel erwartet, von Dir tatsächlich Gründe zu lesen, die gegen einen Einsatz von MySQL bei einem CRM sprechen.

Ich bin sicher kein MySQL-"Fan", beruflich hatte ich bisher nur mit Oracle und MS SQL zu tun, aber ich sehe keinen Grund MySQL zu verteufeln.

Wie gesagt, diese Diskussion können wir gerne woanders weiter besprechen, sie gehört hier nicht her. Hauptgrund Nummer 1: kein PLSQL / kein T-SQL. Weitere Gründe sind vor allem im Sicherheitsbereich zu suchen (Berechtigungskonzept über SSO / AD-Gruppen etc., Verschlüsselung). Bei größeren Installationen auch im Performance-Bereich (MySQL skaliert im Vergleich mit Oracle und SAP zum Beispiel eher schlecht). Ich sage ja nicht, dass MySQL für kleine bis größere Projekt nicht gangbar ist. Ich sage lediglich, dass es für ein CRM (welches man üblicherweise erst ab einer bestimmten Größenordnung und vor allem im Business-Bereich einsetzt) bessere Datenbanken gibt. Es hat schon Gründe, warum Du in der Hauptsache mit MS-SQL und Oracle zu tun hast und ich ebenfalls (MS-SQL schwerpunktmäßig).

MySQL verteufel ich ebenfalls nicht. Ich würde es nur nicht für ein CRM verwenden. Für ein einfaches Web-Bugtracking System: OK. Für ein CRM eher nicht. Für ein ERP gar nicht. Für eine CMDB eher nicht. Für ein Webforum / Wiki klar, warum nicht. Im professionellen Umfeld: Aufgrund der undurchsichtigen Lizenzgebaren von Oracle eher nicht mehr, dann eher MariaDB.

Grüße

PS: Ich arbeite ebenfalls im Versicherungsumfeld. Habe eine GDV-VU-VM-Schnittstelle selbst entwickelt. GDV ISTS + gut beraten WBD via SOAP an unser CRM angebunden und all so Scherze. Ich kenne mich da eventuell "ein klein wenig aus".

 

[Domi83]

Hallo und schönen guten Tag,

ich habe mir jetzt mit ein wenig Hilfe von Dr. Google einen Trigger zusammen gebaut und wollte noch einmal etwas nachfragen, da es sich bei mir ja um eine MySQL / MirandaDB Plattform handelt, sieht mein Syntax für den Trigger wie folgt aus.

CREATE DEFINER=`domi`@`localhost` TRIGGER `trigger_test_update` AFTER UPDATE ON `data_test` FOR EACH ROW BEGIN
 SET @olddata = "{";
 SET @newdata = "{";
 SET @first = true;

 IF(OLD.firstname != NEW.firstname) THEN
  SET @first = false;
  SET @olddata = CONCAT(@olddata, "\"firstname\"", ":", "\"", OLD.firstname, "\"");
  SET @newdata = CONCAT(@newdata, "\"firstname\"", ":", "\"", NEW.firstname, "\"");
 END IF;

 IF(OLD.lastname != NEW.lastname) THEN
  IF(!@first) THEN
   SET @olddata = CONCAT(@olddata, ",");
   SET @newdata = CONCAT(@newdata, ",");
  END IF;

  SET @first = false;
  SET @olddata = CONCAT(@olddata, "\"lastname\"", ":", "\"", OLD.lastname, "\"");
  SET @newdata = CONCAT(@newdata, "\"lastname\"", ":", "\"", NEW.lastname, "\"");
 END IF;

 SET @olddata = CONCAT(@olddata, "}");
 SET @newdata = CONCAT(@newdata, "}");
 INSERT INTO log_test_customers (pdate, `type`, olddata, newdata) VALUES (NOW(), 'update', @olddata, @newdata);
END

Es funktioniert sogar schon... Es werden zwar aktuell nur der Vor- und Nachname bei einem 'update' überprüft, aber mit dem Ergebnis könnte ich schon mal leben. Ich lasse mir auch gleich beide (alte und neue Werte) in die Datenbank packen, bevor doch mal etwas passiert oder etwas abhanden kommt. Lieber etwas zu viel, als zu wenig... oder wie seht ihr das?

Was die Kenntnisse bezüglich GDV und / oder der SOAP Schnittstelle angeht, hört sich schon mal gut an. Bei uns in der Firma ist das etwas komplexer, Chef hat zwei Bereiche. Einmal IT und einmal Versicherungsmakler und das in unterschiedlichen Firmen. Wir aus dem IT Bereich hatten aber auch schon SOAP Schnittstellen angesprochen (selbst bauen mussten wir nicht) um Versicherungen die über unsere Homepage gebucht werden, direkt in das System des Versicherers zu schieben... das war zu Anfang vielleicht komplex und wieso auch immer, mit Anleitungen von Schnittstellenbeschreibungen komme ich besser zurecht, wenn ich auch passende Beispiele dabei sind

Nachtrag1: Mir fällt gerade auf, dass ich wohl mit der genannten Methode und dem Beispiel nicht die 'NULL' Felder prüfen kann. Wenn ich jetzt z.B. den Titel von "NULL => Dr." ändere, kann er dieses nicht protokollieren.

IF(OLD.title != NEW.title) THEN
 IF(!@first) THEN
  SET @olddata = CONCAT(@olddata, ",");
  SET @newdata = CONCAT(@newdata, ",");
 END IF;
 SET @first = false;
 SET @olddata = CONCAT(@olddata, "\"title\"", ":", "\"", OLD.title, "\"");
 SET @newdata = CONCAT(@newdata, "\"title\"", ":", "\"", NEW.title, "\"");
END IF;

Gibt es da einen Tipp / Ansatz für mich?

Nachtrag2: Was mir noch aufgefallen ist, kann ich nicht ähnlich wie in PHP mit einem array() sagen, welche Felder geprüft werden sollen? Das würde mir doch ein wenig Code ersparen

 

[Domi83]

Hallo alle miteinander, ich hätte da noch eine Frage zu dem Thema MySQL und einem ganz normalen INSERT, es geht dabei um folgendes Phänomen... wir haben bei uns in der Firma für jemanden eine Maske gebaut in der er Daten erfassen kann. Funktioniert auch soweit, selbst meine TRIGGER funktionieren, auch wenn ich sie gerne schöner gestalten würde, aber passt schon.

Nun geht es einmal um das Erfassen der Daten... diese werden in unterschiedliche Tabellen aufgeteilt. Der Kunde, seine Bankverbindung, sein gewählte Produkt. SEPA Mandat Referenz ist eine INTEGER, aber nicht die Auto-Inkrementelle ID. Also wird via PHP beim erstellen neuer Daten, einmal ein LOCK TABLE ausgeführt, der aktuellste Wert für das Mandat wird ermittelt und +1 gerechnet. Dieser Datensatz wird via INSERT eingetragen und anschließend wird die Tabelle wieder frei gegeben um nicht mit den Nummern durcheinander zu kommen oder damit Nummern nicht doppelt vergeben werden.

Dieses Verfahren funktioniert seit dem 01.12. Reibungslos, allerdings kam es vergangenen Donnerstag zu dem Phänomen das der LOCK TABLE sehr lange fest stand. Im LOG konnte ich nichts erlesen... vor längerer Zeit kam hier mal der Ansatz, alle Daten erst in einer Zwischentabelle zu sammeln und dann entsprechend in die Tabellen zu schreiben.

Meine Frage wäre nun, erstellt ihr für solch ein Szenario eine Tabelle mit gefühlt 100 Spalten oder macht ihr eine Spalte als MEDIUMTEXT oder so etwas, worin ihr diese Daten sammelt und anschließend wieder verteilt?! Als nächstes würde mich dann nämlich noch interessieren, wenn ihr das Verfahren startet welches die Daten von meiner Zwischentabelle auf A, B und C verteilt, wie verhindert ihr in diesem Fall das nichts dazwischen gerät?

Grund der Anfrage ist halt das auftretende Problem vom vergangenen Donnerstag, welches nur bei zwei Datensätzen auftauchte nach über sieben Monaten, nächster Grund ist... ich würde gerne die Eingabe meines Kollegen etwas optimieren um zu verhindern dass so etwas noch einmal passiert.

Habt Ihr da Stichworte, mit denen ich bei Google die passenden Szenarios finden kann? Über Tipps wäre ich dankbar, denn ich finde selbst das Topic nicht mehr wieder, wo wir das Thema schon mal angesprochen hatten...

Gruß, Domi

 

[mental.dIseASe]

Entweder ich verstehe das Konzept nicht oder es ist sehr verwirrend. Wieso sollte man Sachen erst woanders hindumpen anstatt sie direkt in die dafür bestimmten Tabellen zu schreiben? Das muss deine Businesslogik leisten.

Entität einfügen, ID zurückgeben lassen, Fremdschlüssel in zweiter Entität setzen, zweite Entität einfügen. Oder du baust dir eine Stored Procedure, wo du dann sowas wie ein DTO mit dem ganzen Kram reinsteckst und die ganzen Inserts fährst. Wenn du die Context Switches Richtung DB von der Performance her verkraften kannst, und das sollte bei Inserts regelmäßig der Fall sein, dann würde ich sowas aber immer in der Businesslogik abhandeln. Sollte auch besser wartbar sein.

Und wieso lockt ihr da irgendwelche Tabellen. Gibt es in MySQL keine Sequences?

Ein Integer als SEPA-Mandatsreferenz ist übrigens keine allzu gute Idee. pain, zumindest in Geschmacksrichtung Deutsche Kreditwirtschaft, erlaubt mehr als nur Ziffern. Erfasst ihr mit eurer Maske in Drittanwendungen erstellte Mandate oder erstellt man die mit eurem Tool initial?

 

[Domi83]

Also zu der Frage wieso erst in eine und dann in eine andere Tabelle aufteilen, ging es darum um Datenverluste zu vermeiden wenn Abhängigkeiten wie in unserem Szenario bestehen. Problem ist nur, ich habe gestern Abend noch gesucht aber das Thema nicht mehr gefunden indem das erwähnt wurde. Ich war auch stark der Meinung, dass ich das hier im Forum angesprochen habe, bin aber auch durch die anderen Foren gezogen und habe es nicht mehr wieder gefunden.

Das mit dem SEPA Mandat ist nur ein Teil, im gesamten besteht das SEPA Mandat aus zwei Spalten (wobei es eine auch getan hätte), darunter fällt einmal die Kundennummer in Abhängigkeit zu der Kundentabelle und einer einfachen aufsteigenden Zahl. Diese wird bei Veränderung (ein Update) der Bankverbindung einfach +1 genommen. Da ich selbstständig im Nebenerwerb bin und Lastschriften ziehe, habe ich mich da an meinem Beispiel, an dem was die Bank sagte und einem anderen Unternehmen orientiert. Dort sehen die SEPA Mandate wie folgt aus,
- KD123456-001 (KD = Kunde + Kundennummer + fortlaufende Zahl)

Was die SEQUENCE in MySQL angeht, soweit ich weiß ist das möglich. Ich muss aber gestehen das wir halt keine studierten Informatiker sind und alles das was wir bis jetzt gemacht haben, funktioniert auch. Das neu aufgebaute System meines Kollegen läuft mittlerweile seit 7 Monaten, das von mir erstellte System läuft seit 4 Jahren, aber man möchte ja nicht dumm sterben oder sich darauf ausruhen

Und um solch einen Fehler wie vergangenen Donnerstag zu vermeiden, wollte ich halt noch einmal horchen wie ihr so etwas macht. Aber wenn du das auch für "sinnfrei" empfindest, diese Daten erst in einer Tabelle zu sammeln um sie dann in eine andere zu packen, werde ich mir mal die Prozedur von meinem Kollegen genauer anschauen und versuchen zu optimieren

 

[mental.dIseASe]

Tu das mal. Wenn bei einer einfachen Einfügeoperation das System steht, klingt das für mich nach Datenbank-Deadlock.