Whatever you do I've managed a database of local rescuers veterans, including their full PII, illnesses, statuses, family, etc. Even the floor they lived on an

Whatever you do I've managed a database of local rescuers veterans, including their full PII, illnesses, statuses, family, etc. Even the floor they lived on and how much they drink was in there. It was one form per person with all the data, opened in an instant in a DBF-based system. The "trick" was to store all data in a single table with a few trivially indexed subtables and packed-table-blobs for tabular data. Shocking, I know. It's not "whatever you do", it's a matter of being RDBMS practicioner vs SQL pedant, which is where all the real complexity comes from. If data cannot be collected in a reasonable time for a primary form, it's bad design by definition. It's more reasonable to spend a few minutes to collect a report required once a year than spend a minute on a form required often. Again, not criticizing you for this mess, but it's not something a generic ui framework should solve for.