We’ll be converting a fairly long lease application form into a web application for submission via PHP in to a PostgreSQL database.
I abide by the maxim “Normalize till it hurts, then denormalize till it works” (Attr:SQLMenace) but as I jump in I figured I’d tap the collective mind.
Here is what the paper form currently looks like:
http://www.borgermanagement.com/forms/commercialApplication.pdf
(not the actual form but close)
A lot of the data is mandatory and will be submitted over a couple of views with the option to save a partially completed application for completion at a later date. The submitted application will be reviewed for approval (preferably in one view similar to the pdf). There isn’t likely to be much in-depth analysis of the data down the road.
How would you structure your data in this case?
To normalize or not?
To vertically partition or not?
I would go with a hybrid solution:
Forms “in process” are XML or other “unstructured” data are messages with workflow status. Don’t break out anything other than the fields against which you need to make decisions or find the record later.
Forms that have been fully approved, validated, what have you — store in a fully relational model.
I propose such a solution because you will never have the right business rules (assuming anyone does) to implement the right constraints at every stage of the game — I’ve gone through that a couple of times where I work — so don’t try. Don’t persist a relational implementation until all the unknowns are knowns.