Разработка базы данных для исследования

Ответ 1

Я думаю, что ваша модель № 2 в порядке, однако вы можете взглянуть на более сложную модель, в которой хранятся вопросы и готовые ответы (предлагаемые ответы), и позволяет их повторно использовать в разных опросах.

- В одном опросе может быть много вопросов; один вопрос может быть (повторно) использован во многих опросах.
- Один (готовый) ответ может быть предложен для многих вопросов. На один вопрос может быть много ответов. Вопрос может иметь разные ответы, предлагаемые в разных опросах. В разных опросах можно ответить на разные вопросы. Существует ответ" Другой "по умолчанию, если человек выбирает другого, ее ответ записывается в" Ответ".
- Один человек может участвовать во многих опросах, один человек может ответить на конкретный вопрос в опросе только один раз.

Ответ 2

Моя схема показана ниже.

Последний созданный script находится в https://gist.github.com/durrantm/1e618164fd4acf91e372

Файл script и mysql workbench.mwb также доступны на сайте https://github.com/durrantm/survey

Ответ 3

Определенно вариант № 2, также я думаю, что у вас может быть надзор в текущей схеме, вам может понадобиться другая таблица:

+-----------+
| tblSurvey |
|-----------|
| SurveyId  |
+-----------+

+--------------+
| tblQuestion  |
|--------------|
| QuestionID   |
| SurveyID     |
| QuestionType |
| Question     |
+--------------+

+--------------+
| tblAnswer    |
|--------------|
| AnswerID     |
| QuestionID   |
| Answer       |
+--------------+

+------------------+
| tblUsersAnswer   |
|------------------|
| UserAnswerID     |
| AnswerID         |
| UserID           |
| Response         |
+------------------+

+-----------+
| tblUser   |
|-----------|
| UserID    |
| UserName  |
+-----------+

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

Базы данных предназначены для хранения большого количества данных и очень хорошо масштабируются. Нет реальной потребности в пользователя меньшей нормальной форме просто для экономии пространства.

Ответ 4

Как правило, изменение схемы, основанной на том, что пользователь может изменить (например, добавление вопроса в опрос), следует считать довольно вонючим. Там, где это может быть уместно, особенно при работе с большими объемами данных, но знайте, к чему вы входите, прежде чем погрузиться. Наличие таблицы "ответов" для каждого опроса означает, что добавление или удаление вопросов потенциально очень дорого, и очень сложно делать аналитику вопросно-агностическим способом.

Я думаю, что ваш второй подход лучше всего, но если вы уверены, что у вас будет много проблем с масштабами, одна вещь, которая работала для меня в прошлом, - это гибридный подход:

• Создайте подробные таблицы ответов для хранения ответов на вопрос, как описано в 2. Эти данные, как правило, не будут напрямую запрашиваться из вашего приложения, но будут использоваться для создания сводных данных для таблиц отчетов. Вероятно, вы также захотите реализовать некоторую форму архивирования или исключения для этих данных.
• Также создайте таблицу ответов из 1, если это необходимо. Это можно использовать, когда пользователи хотят видеть простую таблицу для результатов.
• Для любой аналитики, которая должна быть выполнена для целей отчетности, расставьте задания для создания дополнительных сводных данных на основе данных из 1.

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

Ответ 5

Нет 2 выглядит нормально.

Для таблицы с 4 столбцами это не должно быть проблемой даже при наличии нескольких миллионов строк. Конечно, это может зависеть от того, какую базу данных вы используете. Если это что-то вроде SQL Server, тогда это не проблема.

Вероятно, вы захотите создать индекс в поле QuestionID в таблице tblAnswer.

Конечно, вам нужно указать, какую базу данных вы используете, а также оценочные объемы.

Ответ 6

Второй подход лучше всего.

Если вы хотите нормализовать его дальше, вы можете создать таблицу для типов вопросов

Простые вещи:

• Поместите базу данных и зарегистрируйте их собственный диск, а не все на C по умолчанию.
• Создайте базу данных по мере необходимости, чтобы у вас не было пауз, пока база данных растет

У нас были таблицы журналов в таблице SQL Server с 10 миллионами строк.

Ответ 7

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

Ответ 8

Номер 2 правильный. Используйте правильную конструкцию до тех пор, пока не обнаружите проблему с производительностью. Большинство СУБД не будут иметь проблемы с узкой, но очень длинной таблицей.

Ответ 9

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

Ответ 10

При правильном индексе ваше второе решение нормализуется и подходит для традиционной системы реляционных баз данных.

Я не знаю, насколько огромна огромная, но она должна без проблем содержать пару миллионов ответов.

Ответ 11

Вы можете сохранить всю форму в виде строки JSON.

Не уверен в ваших требованиях, но этот подход будет работать в некоторых обстоятельствах.