Как правильно организовать хранение схожих но разных данных в БД?

Question

[Shaidulint]

Здравствуйте, подскажите пожалуйста, как будет правильно организовать хранение схожих данных в БД?
Как пример: Система тестирования: Тест может иметь ряд вопросов, вопросы могут быть трех видов:

• В качестве ответа, нужно будет ввести строку
  
• В качестве ответа, нужно будет выбрать один из предложенных вариантов (radio)
  
• В качестве ответа, нужно будет выбрать один или несколько из предл. вариантов (checkbox)
  

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

Какой из вариантов правильный? Может быть какое то промежуточное решение?
Так же вопрос про EntityFramework (Code second), имеется ли возможность связать модели (тест - вопрос) при втором варианте? А если использовать первый вариант, то модель "Тест" будет иметь три массива с вопросами (на каждый тип по одному)?

Comments

[SharuPoNemnogu]

таблица с вопросами и полем тип, который будет указывать на тип ответов (radio, checkbox..) и таблица ответов с привязкой к id вопроса

Answer 1

[Дмитрий Еремин]

Я, как художник, так вижу

[Tests]
Id | Name | DateCreate | IsDeleted ну и еще, какие вам там надо атрибуты для хранения списка тестов

[Questions]
Id | TestId | QuestionText | AnswerText | IsDeleted + свои атрибуты, какие надо

[Answers]
Id | QuestionId | AnswerText | IsCorrect (является ли ответ правильным или просто вариант) | IsDeleted и т.д.

Как будет работать:
1. берем тест
2. берем N-ый вопрос для этого теста из таблицы вопросов
3. берем K ответов для N-ого вопроса. Варианта 3:

1. К = 0. Ответов в таблице нет - значит вопрос открытый, без вариантов. Сравнивать введенный ответ нужно будет со значением в [Questions].[AnswerText]
   
2. К>1. Ответы есть и правильных (IsCorrect) только один - значит нужно показывать radio
   
3. К>1. Ответы есть и правильных (IsCorrect) больше одного - показываем чек боксы
   

UPD: прочитал ваш коммент
Кажется, я понял вас. Давайте, мой пример, а вы скажете, то или не то.
Интернет магазин электроники. У смартфонов свойства (память, экран, емкость батареи), а у пылесосов (мощность, длина провода, количество насадок). Объекты схожи (товары), но свойства разные и разное количество

Я так делал:
[Item] --товар
Id | Name | CategoryId | Cost | и т.д.

[PropTypes] --виды свойств
Id | Name | Measure (единица измерения, которая будет подписываться. Типа "Мб", "Вт", "Л", "км/ч") и т.д.

[ItemProps] --свойства, которыми обладает товар
Id | ItemId | typeId | и т.д.

[PropValues] - значения свойств
Id | PropId | numValue | textValue | boolValue | dateValue

Можно, конечно PropValues распилить на 4 таблицы, и каждый тип хранить отдельно. Но можно и так. Либо триггер написать, что заполнено может быть только одно поле из 4х (numValue | textValue | boolValue | dateValue).
Либо в коде это учитывать (менее предпочтительно)

Comments

[Shaidulint]

Вопрос не про конткретно с таким примером, а именно про то что бывает сущность схожая, но разная. Например аналогичный пример, таблица с документами. У документов бывают различные (плавующее кол-во, мб сколько угодно) свойства. Свойсвтва бывают трех видов: строки, числа, даты. Их хранить лучше в трех разных таблицах. Как их правильно соединить с таблицей документов, так что бы это было правильно с идеологической стороны БД. А не со стороны, как проще. Так что бы больше проверок повесить на БД.

[Shaidulint]

Спасибо за ответ, такой вариант тоже рассматривался, но при количестве данных (объектов) в миллионах и множестве свойств у каждого возникает проблема с ростом памяти БД, так как NULL жрут место вроде как. А так же тяжело правильно и логично обвязать БД моделями Entity Framework.