Что лучше: 1 таблица на запись или 1 таблица со всеми записями, связанными с внешними ключами?

Question

У меня есть приложение, которое позволяет пользователям создавать различные формы (опросы), а затем заполнять их.(поэтому он заменяет бумагу).

Вот текущая модель, которую я использую в приложении:

 Table 1)
+-------------------------+
|      SURVEYS TABLE      |   
+----+------+-------------+
| ID | name | description |  
+----+------+-------------+

 Table 2)   
+-----------------------------------+
|       $[name_of_the_survey]       |
+----+-------+------+-------+-------+
| ID | field | type | value | items |
+----+-------+------+-------+-------+


 Table 3)
+--------------------------------------+
|    $[name_of_the_survey] _records    |
+----+---------------------------------+
| ID | columns specific to each survey |
+----+---------------------------------+

, поэтому, когда пользователь создает опрос, программы обычно вставляют записьв Surveys Table, а затем создает 2 таблицы:

table (2) для полей таблицы формы (3) для записей, которые будут храниться, в которых столбцы соответствуют строкам таблицы (2).

Работает, но имеет некоторые ограничения.Например, когда вам нужно добавить поле в таблицу (2), он должен прочитать содержимое таблицы (3), сохранить его в виртуальной таблице, удалить предыдущую таблицу (3) и создать новую.Это может быть проблемой производительности, когда таблица (3) имеет много записей.

Итак, мой вопрос ... Есть ли лучший дизайн базы данных?

Answer 1

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

Однако вам нужны три таблицы: определение опроса, вопросы опроса и ответы на опросы. Это может выглядеть примерно так ...

Surveys:
ID; name; description

Questions:
ID; text; surveyID

Answers:
ID; answer; questionID

Вы можете добавить сложность для обработки перечисленных ответов ...

Surveys:
ID; name; description

Questions:
ID; text; surveyID

Choices:
ID; choice; questionID

Answers:
ID; choiceID

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

Answer 2

Вы можете попробовать взглянуть на http://en.wikipedia.org/wiki/Database_normalization#Normal_forms

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

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