Dauer eines Insert - php sleep()

[razer2k]

Hallo zusammen!

Ich habe ein kleines Problem:

Und zwar lege ich mit einem Script einen neuen Datensatz in einer Tabelle an. Sobald das passiert ist, leite ich den Nutzer auf eine Seite weiter, auf der der neue Datensatz angezeigt wird.
Das ganze läuft folgendermaßen:
Ich suche mit mysql_insert_id() die eben eingefügte ID und rufe danach die PHP-Header Funktion in dieser Art auf:

header("Location: anzeigen.php?id=".$neueId);

D.h. sobald der Speichervorgang abgeschlossen ist und ich die neue Id erhalten haben, wird man direkt weitergeleitet.

Nun erhalte ich jedoch immer die Meldung in der anzeigen.php, dass der Datensatz nicht vorhanden ist. Lade ich die anzeigen.php mit der entsprechenden Id neu, dann funktioniert alles.

Ich hatte jetzt den Verdacht, dass evtl. die Datenbank "noch nicht fertig ist" und habe ein sleep(1); vor das Senden des Headers eingebaut. Das funktioniert auch prima

Meine Frage ist nun aber, wie kann das denn überhaupt sein? Schließlich bekomme ich doch schon die neue Id übergeben, d.h. der Datensatz müsste doch schon existieren. Wieso wird er jedoch nicht gefunden, wenn ich das Script nicht kurz pausiere?

Viele Grüße,
Jan

[onemorenerd]

Wie sieht dein INSERT-Statement aus? Verzögerst du das Schreiben? Wahrscheinlich nicht, aber man hat ja schon Pferde kotzen sehen ...

Ist es ein singulärer DB-Server oder hast du irgendeine Form von Replikation (Master/Slave) laufen?

Wenn es kein V- oder Root-Server ist, welcher Provider ist es dann?

Was passiert, wenn du den Datensatz gleich noch mal SELECTest, bevor du die Header sendest? Ist er dann auch nicht da?

Welche Storage Engine benutzt du, MyISAM?

[razer2k]

Hey!

Ich habe zwei Tabellen, eine "Index"-Tabelle und eine "Content"-Tabelle, um eine History-Funktion zu gewährleisten. Ich kann also Einträge aktualisieren, ohne dass ich Datensätze löschen muss. Die "Index"-Tabelle enthält nur Werte, wie z.B. ursprünglicher Autor, Erstellungsdatum oder Status (aktiviert/deaktiviert), die "Content"-Tabelle enthält den eigentlichen Datensatz.

Der Erstellungs-Vorgang sieht so aus:
- Neuen Datensatz in Index-Tabelle anlegen
- Neue Index-Id abfragen
- Neuen Datensatz (mit Verknüpfung zur Index-Id) in Content-Tabelle schreiben)
- Neue Content-ID in Index-Tabellen-Datensatz updaten

Der Update-Vorgang sieht so aus:
- Alten Datensatz öffnen
- Neuen Datensatz in Contentabelle schreiben
- Neue ID des Contents in Index-Tabelle updaten

Das Problem tritt sowohl beim Erstellen, als auch beim Updaten auf.

Das Schreiben verzögere ich nicht. Außerdem warte ich das result ab und prüfe es auf true, ansonsten schmeiße ich eine Exception.
Zum DB-Server kann ich nicht viel sagen, ich habe bei Domainfactory einen Managed-Server-Tarif. Allerdings tritt das Problem auf lokal mit Xampp auf. Ich nutzte MySQL5 und InnoDB.

Ich probiere mal deinen Vorschlag aus!

Viele Grüße,
Jan

[onemorenerd]

Sowas wie "In Tabelle A eintragen, ID lesen, in Tabelle B eintragen, ID lesen und in Tabelle A updaten" ist so ziemlich das umständlichste, was man sich ausdenken kann.
Ich hoffe doch sehr, dass dein DB-Schema das Ergebnis einer Normalisierung ist. Aber dennoch solltest du die beiden Tabellen vereinen, sofern sich das mit der Anwendungslogik verträgt oder wenigstens mit Foreign Key Constraints arbeiten.

[razer2k]

Original geschrieben von onemorenerd
Sowas wie "In Tabelle A eintragen, ID lesen, in Tabelle B eintragen, ID lesen und in Tabelle A updaten" ist so ziemlich das umständlichste, was man sich ausdenken kann.
Ich hoffe doch sehr, dass dein DB-Schema das Ergebnis einer Normalisierung ist. Aber dennoch solltest du die beiden Tabellen vereinen, sofern sich das mit der Anwendungslogik verträgt oder wenigstens mit Foreign Key Constraints arbeiten.

Hallo!
Danke für den Hinweis, sowas ist immer gut, um jahrelang eingefahrene Angewohnheiten nochmal zu überdenken!
Der Gedanke war ursprünglich, keine redundanten Daten zu haben. Die Index-Tabelle enthält neun Spalten. Würde ich die beiden Tabellen zusammenführen, würde diese 9 Spalten bei jedem Inhalts-Datensatz mitgespeichert werden, wären also doppelt vorhanden. Dazu kommt, es gibt teilweise sehr viele Inhaltsdatensätze (Versionen) zu einem Indexeintrag, die dann alle dieselben Index-Daten enthalten würden. Weiterhin für diese Struktur spricht für mich, wenn ich z.B. einem Index-Eintrag einen Status zuweise, der unabhängig vom Inhaltsdatensatz ist, also eine der neun Spalten ändere, dann muss ich dies nur bei einem (dem Index-Datensatz) machen. Habe ich beide Tabellen zusammengeführt, muss ich theoretisch bei allen Datensätzen die Index-Spalten updaten, damit diese alle aktuell sind. Denn lösche ich einen neueren Inhaltsdatensatz, so dass ein älterer wieder aktuell wird, würden die Indexspalten dort falsche Daten enthalten.

Ich hoffe das ist einigermaßen verständlich

Sollte das deiner Meinung nach auch noch über eine einzige Tabelle gelöst werden?

Viele Grüße,
Jan

[onemorenerd]

Deine Argumente entsprechen der Theorie der Normalisierung. In der Praxis zeigt sich aber manchmal, dass man nicht unbedingt vollständig normalisieren sollte.

Beispielsweise hat das Argument der Redundanz zwei Kostenfaktoren:
1. Duplikate erfordern zusätzlichen Speicherplatz und
2. bei Änderungen sind mehrere Datensätze betroffen.
Aber Speicherplatz ist billig und wenn die Daten nur selten geändert werden, sondern praktisch nur eingefügt oder gelöscht, dann gibt es keine teuren Änderungen.

Es gibt also Szenarien, bei denen es durchaus sinnvoller ist, von der Theorie abzuweichen und auf Praxistauglichkeit zu optimieren. Ob das bei nun gerade der Fall ist, möchte ich nicht beurteilen. Dazu muss man schon ein genaues Bild über DB-Inhalte, Applikationslogik und Anforderungen haben.

Hast du eigentlich den Fehler in deiner Applikation schon gefunden? Die partielle De-Normalisierung würde den nämlich nicht zwangsläufig ausmerzen. Es kann eine Lösung sein, muss aber nicht.