Есть что-то вроде такой базы:
Inquiry(id, name) — опрос.
InquiryQuestion(id, inquiry_id, name) — вопрос, входящий в состав опроса
InquiryQuestionCase(id, inquiry_question_id, name) — вариант ответа
InquiryVote(id, user_id, inquiry_question_case_id) — ответ юзера
Суть — опрос. Опрос состоит из вопросов, какждый из который в свою очередь состоит из вариантов ответа. Юзер может проголосовать только один раз и при этом в качестве ответа на конкретный вопрос может выбрать только один кейз. В общем, классика.
Так вот... В том варианте, который я привёл, никаких проблемм с НФ нет, но вот такие проблемы, как ответ пользователя двумя вариантами на один вопрос или повторное участие в голосовании, приходится отлавливать на уровне кода, а хотелось бы обойти это как-то красивым дизайном базы.
К примеру, если попробовать решить проблему, связанную с голосованием с одновременным выбором нескольких ответов, то первое, что приходит в голову, это такой редизайн последней таблицы:
InquiryVote(id, user_id, inquiry_question_id, inquiry_question_case_id)
В общем, делаем unique на (user_id, inquiry_question_id, inquiry_question_case_id) и всё ровненько! Ну вообще-то не очень ровненько. Тут начинает появляться неприятный зуд насчёт НФ No. X (какой, кстати? я не спец), т.к. появляется явная повторная зависимость inquiry_question_case_id -> inquiry_question_id. Возможно, оно и не сильно страшно, но зудеть от этого не перестаёт.
В итоге, собственно, вопрос: какой ещё вариант диза можно рассмотреть для уничтожения обоих зайцев?
PS Я проектирования БД как-то никогда особо не касался, а тут вот пришлось код порефачить, а вместе с ним и базу, так что если вопрос идиотский, не ругайтесь, пожалуйста, дайте ссылку. Я долго искал, честное пионерское...
