There is probably a name for that. Please rename accordingly
I appreciate the idea of building a set of generic database tables that will store user input. Then there will be a secondary process to start the workflow and process the input.
The idea is that the concept of storing initial user input is decoupled from processing and placed in a structured schema for a specific application.
An example would be an application or an open-ended question survey. The raw answers will not be very valuable to us for summary reporting without some kind of human classification. But we want to keep the original input as a historical record.
We may also want the user to be able to partially fill in some information and save it until he returns.
Processing all input to the point where we can put it in our application-specific data schema may not be possible until we have ALL the data.
Two initial questions:
- Assuming this concept has a name, what is it?
- Is this a sane approach? Why or why not?
Update:
Here's another way to get your idea across. The user sequentially fills in the fields in the DTO. I (think I) want to save the DTO to disk even in a partially-complete state. Once the user is done filling in the fields, I want to pull out the DTO and process it for a structured save to a table that represents the particular DTO. However, I cannot save a partially completed or (even worse) temporarily invalid input set, since some of the input really shouldn't be stored as part of a structured record.
My idea is to create some kind of generic way to store any type of DTO and then pull them out for processing in a specific application as needed. Therefore, it is possible that this shared DTO stores data pertaining to customer satisfaction surveys alongside the questions asked in the new Account Setup Wizard.
a source to share
You stated:
My idea is to create some kind of generic way to store any type of DTO and then pull them out for processing in a specific application as needed.
I think you are one level of abstraction. I would argue that the entire database serves the role you want for a limited set of tables. You could create some kind of complex storage scheme that doesn't represent the data in any way, and then (slowly and painfully, from a DBMS perspective) merge and render the data ... but I would assume this is a reworked solution.
I have written several applications where, due to user requirements, (sometimes a significant) part of the application is dynamically created by the user, from schema to business rules. Those that fabricated their storage schemas by executing statements such as CREATE TABLE and ALTER TABLE were, surprisingly, the easiest to maintain. They also allow users to create reports in a very simple, expected way.
a source to share
You may be talking about Workflow. You might want to check Windows Workflow .
Workflow concepts are that they reflect real life processes. That is, you are making a complete document, but the document is not finalized until it is approved. In your case it will be "Data entered", but unclassified, so it is stored in the database (dehydrated) and the flag is sent to those who need a solution to this problem. It can be kept in this state for as long as necessary. When someone can handle it, the workflow starts again (hydrates) and moves on to the next steps.
Here are some questions about workflows:
This question, " Is it better to have one large workflow, or several smaller specific ones? " Clears up some of the ways in which the workflow is used, and also highlights some of the problems with it.
John Saunders is very well versed in what workflow is good for this question .
a source to share