Die Idee mit der Datenbank ist sicherlich sehr interessant, erfordert aber noch ein bisschen Nachdenken, denn das fällt in die Kategorie "Transaktionsmanagement" und automatische Persistenz der Daten. Beim Abschicken des ersten Formulars wird das zweite Formular aufgerufen, dass schaut, von wem es aufgerufen wurde (dem ersten) und die übergebenen Daten unter einer eindeutigen Transaktions-ID in die Tabelle schreibt. Problem ist, dass man die Transaktion wiedererkennen muss ! Dafür kommt in diesem Beispiel zum Beispiel ein hidden-field in Frage, das beim allerersten Formularaufruf initial gesetzt wird und der Transaktions-ID in der DB entspricht.
Klickt der User in Formular5 auf Submit, wird die Transaktion beendet, die Aktion der Transaktion ausgeführt und die temporären Transaktionsdaten in der Tabelle ggf. wieder gelöscht (was will man schon damit ?), bzw. als ausgeführte Transaktion in der Tabelle gesichert.
---
Ich würde allerdings einen anderen Weg wählen, und zwar den über Sessions. So spart man sich das Transaktions-Handling. Hierfür brauchst Du eine Datenklasse, die alle Daten hält, die in irgendeinem Formular eingegeben werden. Beim ersten Aufruf checkt das 1.Formular, ob der User bereits eine Session-ID, bzw. ein gülitges Datenobjekt hat. Wenn nicht, wird ein einziges (leeres) Datenobjekt angelegt und in einer Session-Variable gespeichert. Submitted der User das erste Formular, schaut das zweite Formular wieder, von wo es aufgerufen wurde und deserialisiert (session_decode) das Datenobjekt. Die Felder des Datenobjekts für Formular1 werden von Form2 gefüllt und anschließend das Datenobjekt wieder in die Session-Variable serialisiert (session_encode).
Am Ende (nach Formular5) steht nun eine Transaktionsseite, die die Daten aus Formular 5 und ein (vollständiges)Datenobjekt via Session entgegennimmt. Diese Seite führt die eigentliche Aktion aus, speichert ggf. das Datenobjekt in einer SQL-Repräsentation in der Datenbank und wirft das Datenobjekt aus der User-Session (session_unset).