Background: I am developing a wizard based web form where users can log in an fill in some details and press next and previous to go back and forth in the wizard before they actually submit. When the user submits I would make a service call that performs some processing on the data.Issue: Not all data is available readily to the user, and the user may choose to save the data instead of submitting it, and then come back (if s/he chooses to) and finish it later. This intermediate data would be incomplete (and in some cases invalid) - but for convenience we would let the user save it.Solutions I seen in the past: In the past I have dealt with this with 2 distinct solutions -Save the intermediate data in the regular tables (where submitted data is saved) and mark that data as inactive. The data would be activated only when the user clicks submit and all data is valid. This involves modifying the service that is called on submit to accept the data on save the intermediate and invalid data. Also this puts the burden on the team to remember to check for active flag in every query.The other option is to storing the intermediate saved data in huge denormalized CLOBs. The data could be structured within the CLOBs as an XML or JSON. The intermediate data (saved) is completely disjoint from the completed (submitted). The downside here is that now the form needs to be able to work with 2 different sets of services based on the status of the workflow cycle (if in-progress read the XML from the CLOB  if completed read from the service that has valid data!)Question:Is there a better way to solve this problem since it does seem like a universal issue in the enterprise world at least? Could someone point me to any data or storage patterns that the community has been following to solve this storage issue in web workflows?Note:The underlying database technology can be thought of a system that supports tables and individual fields can contain very large strings like CLOBs.
Data Storage patterns for intermediate saving a web-based workflow form
workflows;storage;webforms;date patterns