Дизайн базы данных анкеты - какой путь лучше?

У меня есть ОДНА длинная HTML-страница, несколько наборов вопросов, разделенных на небольшие разделы (около 15 подразделов на одной странице), общее количество вопросов составляет около 100 вопросов: варьируется от ввода, множественного выбора, флажков, переключателей, текстовой области, и загрузка файла. Один вопрос может содержать много ответов, которые получены либо из группы флажков, группы из списка выбора, группы из нескольких вариантов, либо из всех них, объединенных в один ответ. Я думал, что буду использовать этот дизайн базы данных ниже, но недавно узнал, что это не очень хороший подход в конце концов.

1. У одного клиента может быть только один набор вопросов: один клиент на 100 вопросов.
2. Для старого подхода я не сохраняю вопрос в базе данных, а вместо этого назначаю константу в кодировании PHP. Проблема в том, что мне нужно сравнить вопрос в PHP, чтобы синхронизировать его с ответом в базе данных. Если бы один вопрос был изменен / удален / перемещен из PHP, я определенно потерялся бы, чтобы сопоставить его с ответом в базе данных Анкеты. Лучшее решение?
3. Могу ли я сохранить несколько ответов, полученных из нескольких элементов формы, в одном поле как один ответ? Как я могу получить это поле и снова отобразить его для просмотра клиентом в форме?
4. Какой вариант ниже я должен пойти?

ВАРИАНТ 1: Старый подход (1 таблица)

ТАБЛИЦА: Анкета

• ID (PK)
• Пользовательский ИД
• Положение дел
• A1
• A2
• A3
• ,
• ,
• ,
• A100

ВАРИАНТ 2: Новый подход (2 таблицы)

ТАБЛИЦА: Вопрос

• QID (PK)
• Вопрос (varchar)

ТАБЛИЦА: Ответ

• ПОМОЩЬ (ПК)
• Пользовательский ИД
• QID (int)
• Ответ (varchar)

Или ВАРИАНТ 3?

Определенно, не используйте жесткий код вашей анкеты. Используйте реляционную базу данных или XML-файлы. Я предлагаю следующие таблицы

• Questionnaire: Общее описание анкеты. Название, название опроса, дата выпуска анкеты, версия и т. Д.

• Section: Разделы анкеты составлены. Номер раздела, название раздела, описание.

• Question: Вопросы, относящиеся к разделу. Номер вопроса, текст вопроса, описание, тип вопроса (текст, множественный выбор и т. Д.).

• Question_Choice: Возможные ответы на вопрос, соответствующий отдельным флажкам, переключателям и т. Д. Текст выбора, номер выбора, заказ.

• Respondent: Лица, отвечающие на вопросы. Персональные данные, номер пользователя.

• Interview: Интервью или тесты или опросы (в зависимости от характера вопросника), принадлежащие одному респонденту и одному вопроснику. Если респондент всегда может ответить только на один вопросник (или если опрос является анонимным), эта таблица устарела и может быть объединена с таблицей респондентов. Дата интервью (или дата тестирования или дата опроса), интервьюер (если это применимо).

• AnswerОтветы, относящиеся к одному интервью (или респонденту, см. Выше) и одному вопросу. Текст ответа (для вопросов типа текста), выбор (для переключателей).

• Answer_Choice: Варианты, принадлежащие одному Ответу и одному Вопросу-Выбору, когда можно проверить несколько вариантов.

Это очень нормализованный подход; тем не менее, вы можете решить объединить варианты в одну строку или сохранить их как битовую комбинацию или упростить ее другим способом в зависимости от ваших потребностей.

Вам нужно несколько столов,

1 - Вопросы (идентификатор вопроса, тип ввода, видимый, тип вопроса, текст вопроса, ожидаемые ответы ....)

2 - Ответы (идентификатор вопроса, идентификатор пользователя, идентификатор активности, ответ ....)

3 - пользователи (идентификатор пользователя, имя пользователя ......)

4 - Таблица для хранения вопросов / ответов (идентификатор активности, данные / время, идентификатор пользователя)

Вам также может понравиться таблица, в которой указаны вопросы, которые следует применять к каждому виду деятельности - либо сгруппированные по пользователям, либо, возможно, набор вопросов. Внешние / первичные ключи будут столбцами с одинаковыми именами в нескольких таблицах и должны быть проиндексированы.

Если вы используете эту структуру, вы сможете добавить вопрос или пользователя или изменить ответ без необходимости изменения схемы или кода презентации - убедитесь, что код презентации создается динамически во время выполнения - вам просто нужно добавить запись в соответствующем месте.

Этот подход может занять больше времени для первоначальной разработки, чем жестко запрограммированный, но его будет намного проще поддерживать, поскольку вам нужно будет только изменить данные, чтобы изменить поведение.

(Подсказка: для создания слоя презентации вам понадобится запрос, который отображает соответствующие вопросы, а затем переберите этот набор результатов и вызовите метод для рендеринга в вопрос на экране, а выбранные методы будут соответствовать представление этого вопроса [текстовое поле, радиогруппа и т. д.))