Проектирование баз данных для [закрытого] обзора

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот простые вещи:

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

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

Хорошо выглядит № 2.

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

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

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

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

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

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

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

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

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