Есть что-то вроде такой базы:
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 Я проектирования БД как-то никогда особо не касался, а тут вот пришлось код порефачить, а вместе с ним и базу, так что если вопрос идиотский, не ругайтесь, пожалуйста, дайте ссылку. Я долго искал, честное пионерское...
Здравствуйте, Sh1ZoID, Вы писали:
SZI>Всем привет.
SZI>Есть что-то вроде такой базы: SZI>Inquiry(id, name) — опрос. SZI>InquiryQuestion(id, inquiry_id, name) — вопрос, входящий в состав опроса SZI>InquiryQuestionCase(id, inquiry_question_id, name) — вариант ответа SZI>InquiryVote(id, user_id, inquiry_question_case_id) — ответ юзера
SZI>Суть — опрос. Опрос состоит из вопросов, какждый из который в свою очередь состоит из вариантов ответа. Юзер может проголосовать только один раз и при этом в качестве ответа на конкретный вопрос может выбрать только один кейз. В общем, классика.
SZI>Так вот... В том варианте, который я привёл, никаких проблемм с НФ нет, но вот такие проблемы, как ответ пользователя двумя вариантами на один вопрос или повторное участие в голосовании, приходится отлавливать на уровне кода, а хотелось бы обойти это как-то красивым дизайном базы.
SZI>К примеру, если попробовать решить проблему, связанную с голосованием с одновременным выбором нескольких ответов, то первое, что приходит в голову, это такой редизайн последней таблицы: SZI>InquiryVote(id, user_id, inquiry_question_id, inquiry_question_case_id) SZI>В общем, делаем unique на (user_id, inquiry_question_id, inquiry_question_case_id) и всё ровненько! Ну вообще-то не очень ровненько. Тут начинает появляться неприятный зуд насчёт НФ No. X (какой, кстати? я не спец), т.к. появляется явная повторная зависимость inquiry_question_case_id -> inquiry_question_id. Возможно, оно и не сильно страшно, но зудеть от этого не перестаёт.
SZI>В итоге, собственно, вопрос: какой ещё вариант диза можно рассмотреть для уничтожения обоих зайцев?
SZI>PS Я проектирования БД как-то никогда особо не касался, а тут вот пришлось код порефачить, а вместе с ним и базу, так что если вопрос идиотский, не ругайтесь, пожалуйста, дайте ссылку. Я долго искал, честное пионерское...
. В моем дизайне на один вопрос можно дать единственный ответ. Если допускаются множественные ответы на один и тот же вопрос, то надо сделать первичный ключ в таблице Questionnaire из столбцов (RespondentId, QuestionId, AnswerId).
>надо сделать первичный ключ в таблице Questionnaire из столбцов >(RespondentId, QuestionId, AnswerId)
Не слушай его, pk по многим полям — зло. Для уникальности предназначен
unique index.
Posted via RSDN NNTP Server 2.1 beta
Данное сообщение является художественным произведением и освещает вымышленные события в вымышленном мире. Все совпадения с реальностью являются случайными. Не является инвестиционной рекомендацией.
Здравствуйте, Osaka, Вы писали:
>>надо сделать первичный ключ в таблице Questionnaire из столбцов >>(RespondentId, QuestionId, AnswerId) O>Не слушай его, pk по многим полям — зло. Для уникальности предназначен O>unique index.
FD>И почему это зло ?
1) он может поменяться (то что меняющийся pk это зло, надеюсь возражений не вызывает?)
2) на него тяжело ссылаться (вставлять или писать сравнения — по нескольким полям)
Куча дополнительных трудностей, и в микроскоп не различимая экономия.
Данное сообщение является художественным произведением и освещает вымышленные события в вымышленном мире. Все совпадения с реальностью являются случайными. Не является инвестиционной рекомендацией.
Здравствуйте, Osaka, Вы писали:
FD>>И почему это зло ? O>1) он может поменяться (то что меняющийся pk это зло, надеюсь возражений не вызывает?)
PK в этой таблице не меняется. Или имеется в виду, что PK из одной колонки не может поменяться, а PK из трех колонок может ? ТОгда это новое слово в теории реляционных БД.
O>2) на него тяжело ссылаться (вставлять или писать сравнения — по нескольким полям)
На эту таблицу никто не ссылается. Если будет кто-то ссылаться, можно будет добавить суррогатный PK из одной колонки.
O>Куча дополнительных трудностей, и в микроскоп не различимая экономия.
Какие еще "дополнительные трудности" ?
Re[3]: Дизайн БД - как лучше?
От:
Аноним
Дата:
12.12.11 16:49
Оценка:
Здравствуйте, Osaka, Вы писали:
>>надо сделать первичный ключ в таблице Questionnaire из столбцов >>(RespondentId, QuestionId, AnswerId) O>Не слушай его, pk по многим полям — зло. Для уникальности предназначен O>unique index.
А мне по-другому и нельзя, я с ORM джанговской работаю (там у всех таблиц суррогатный pk), да и, как я понимаю, PK имелся в виду как условность, конечно я попросту unique together сделаю
. В моем дизайне на один вопрос можно дать единственный ответ. Если допускаются множественные ответы на один и тот же вопрос, то надо сделать первичный ключ в таблице Questionnaire из столбцов (RespondentId, QuestionId, AnswerId).
Идея отличная, спасибо, но я могу ссылаться только через суррогат, никаких составных ключей — ограничение ORM(
