Database design suggestions for large, multi-part questionairre
Are there any good database design patterns for applications that collect many pieces of seemingly unrelated data?

I'm helping out with an app that will include a large, multi-part form, similar to an insurance application. There will be 60-80 questions in this form. Many of the questions are yes/no. Some do seem to be logically related, such as several questions yes/no questions on a person's criminal background, but they're really not true relational data in the same way that a mailing address relates to a user.

The most logical way to view this data is as a unit--the form itself. But that would be a massive table and would become a nightmare.

I've also thought about having a table for questions and another table for answers, where each row maps one user to one answer with a link back to the question. One drawback here is that all answers would end up being `varchar`.

It seems like there has to be a better way. Any suggestions?
Database design suggestions for large, multi-part questionairre
===

Are there any good database design patterns for applications that collect many pieces of seemingly unrelated data?

I'm helping out with an app that will include a large, multi-part form, similar to an insurance application. There will be 60-80 questions in this form. Many of the questions are yes/no. Some do seem to be logically related, such as several questions yes/no questions on a person's criminal background, but they're really not true relational data in the same way that a mailing address relates to a user.

The most logical way to view this data is as a unit--the form itself. But that would be a massive table and would become a nightmare.

I've also thought about having a table for questions and another table for answers, where each row maps one user to one answer with a link back to the question. One drawback here is that all answers would end up being `varchar`.

It seems like there has to be a better way. Any suggestions?