Не раз встречалась ситуация, когда необходима связь таблиц, в которых ключ в последующей таблице является ключем предыдущей + уникальный столбец, например, задача следующая:
Требуется БД для хранения тестов (пользователи сами добавляют сколько угодно тестов, сами добавляют варианты ответов )
В БД "Тесты" есть Таблицы, жирным - ключ таблицы:
Пользователи (id_юзера, почта и т.д.)
Тесты_пользователей (id_юзера, id_теста, назание_теста, осписание_теста и т.д.)
Вопросы_тестов_пользователей (id_юзера, id_теста, id_вопроса, сам_вопрос и т.д.)
Или, например, по той же схеме БД для хранения результатов тренировок (пользователи создают программу тренировок, в нее добавляют скажем 3 дня тренировок, в них накидывают упражнения для каждого из них)
Пользователи, Программы_тренировок_пользователей, Номера_тренировок_программ_пользователей, упражнения_номеров_тренировок_ программ
И в итоге результат сохраняется в таблице с множеством внешних ключей.
Правильный ли это подход или может стоит пересмотреть что-то, может литературу какую-нибудь посоветуете по БД?
Как лучше хранить варианты ответов - отдельными строками в БД или прямо в таблице с вопросом в отдельном поле, а потом парсить вывод?
Интересует хранение тестов, где разрозненная структура, т.е. один вопрос может быть чекбоксами, другой радиокнопками, третий - пользователь сам вводит ответ. Как это лучше хранить? Спасибо.
Ну вот для "Тесты_пользователей" поле "id_юзера" это внешний ключ на юзера. Тут нормально. А для "Вопросы_тестов_пользователей" хранение "id_юзера" уже бессмысленно, т.к. есть "id_теста" и всегда можно заджоинить.
По поводу "один вопрос может быть чекбоксами, другой радиокнопками". Можно ввести параметр внутри таблицы вопросов, который отвечает за тип вариантов ответа - RADIO|CHECKBOX|INPUT. И в зависимости от этого типа на UI рисовать нужные поля для вариантов (если они есть).
Варианты ответов лучше хранить в отдельной таблице, деструктурированные данные гораздо проще использовать. Просто задаем внешний ключ на "id_вопроса"
Спасибо, вопрос добавляет сам пользователь, т.е. он уникален для данного вопроса текущего пользователя. Сам пользователь системы составляет тест, а их (пользователей) может быть много.
По поводу вариантов ответов - да, проще использовать и правильнее с точки зрения атомарности отдельными строками, просто замечал в БД некоторых хранение напр., в json - или будет 10 строк или одна, но все внутри нее, с точки зрения оптимизации при большой БД вот интересно как лучше
Kroenke, David M., Auer, David J. Database Processing.
Connolly, Thomas M., Begg, Carolyn E. Database Systems: A Practical Approach to Design, Implementation, and Management.
Простой
