Дизайн базы данных для нескольких подобных типов?

Question

Скажем, у меня есть два типа вопросов: множественный выбор и диапазон. Вопрос диапазона позволяет пользователям ответить, указав диапазон значений в своем ответе (например, 1-10 или 2-4).

Я унаследовал базу данных, где ответы на эти типы вопросов сохраняются в той же таблице, которая структурирована таким образом:

Answers 
------- 
Id 
QuestionId 
choice 
range_from 
range_to 

Это приводит данные, как показано ниже:

1 1 null 1  10 
2 1 null 2  4 
3 2 Pants null null 
4 2 Hat null null 

ли это иметь смысл включать столбцы из каждого типа ответа в таблице ответов? Или они должны быть разбиты на отдельные таблицы?

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

Answer 1

Имеет ли смысл включать столбцы из каждого типа ответов в таблице ответов?

Это стратегия «все классы в той же таблице» для реализации наследования, которая подходит для небольшого количества классов. По мере роста числа классов вы можете рассмотреть один из other strategies. Для этого нет предопределенной «точки отсечения» - вам придется измерять и решать сами.

Альтернативой будет EAV-подобная система as proposed by blotto, но это сместит выполнение согласованности данных в сторону от СУБД. Это допустимое решение, если вы не знаете структуру данных во время разработки и хотите избежать DML во время выполнения, но если вы знаете структуру данных во время разработки, лучше придерживайтесь наследования.

Answer 2

У вас может быть одно поле, представляющее «тип» вопроса, который лучше всего подходит в таблице «Вопрос» (а не в таблице «Ответ»). Например:

question_type ENUM('choice', 'range', 'type_3', 'type_4'..) 

Затем сделайте ссылку один-ко-многим (объединение таблицы), которая представляет собой вопрос-к-ответы отношения

AnswerId (pk) | QuestionId (fk) 
1    1 
2    1 
3    2 
4    2 

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

answer_type ENUM('low_range', 'high_range', 'choice', etc) 

Id (pk)| AnswerId (fk) | Type  | Value 
1  1    low_range  1 
2  1    high_range  10 
3  2    low_range  2 
4  2    high_range  4 
5  3    choice   Pants 
6  4    choice   Hat 

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