Conversion de formulaires papier/PDF pour le Web - Normalize, Partition ou Wide-Table?

Question

Nous allons convertir un formulaire de demande de bail assez long en une application web pour la soumission via PHP dans une base de données PostgreSQL. Je respecte la maxime «Normaliser jusqu'à ce que ça fasse mal, puis dénormaliser jusqu'à ce que ça marche» (Attr: SQLMenace) mais en y entrant je me suis dit que j'allais puiser dans l'esprit collectif.

Voici ce que la forme de papier ressemble actuellement: http://www.borgermanagement.com/forms/commercialApplication.pdf (pas la forme réelle mais proche)

Beaucoup de données est obligatoire et sera soumis sur deux vues avec la possibilité d'enregistrer une demande partiellement remplie pour être complétée à une date ultérieure. La demande soumise sera examinée pour approbation (de préférence dans une vue similaire au pdf). Il n'y aura probablement pas d'analyse approfondie des données sur la route.

Comment structureriez-vous vos données dans ce cas? Normaliser ou non? Pour partitionner verticalement ou non?

Answer 1

Je voudrais aller avec une solution hybride:

1. formes « en cours » sont XML ou d'autres données « non structurées » sont des messages avec l'état des flux de travail. N'éclatez rien d'autre que les champs pour lesquels vous devez prendre des décisions ou retrouvez l'enregistrement ultérieurement.

2. Formulaires entièrement validés, validés, que stockez-vous dans un modèle entièrement relationnel?

Je propose une telle solution parce que vous aurez jamais les règles de droit des affaires (en supposant quelqu'un ne) à mettre en œuvre les contraintes à droite à chaque étape du jeu - je suis allé à travers ce deux ou trois fois où Je travaille - alors n'essayez pas. Ne pas persister une implémentation relationnelle jusqu'à ce que toutes les inconnues soient connues.