дизайн реляционной базы данных для многомерных матричных вопросов

Я не согласен с ryan1234. Это полностью реляционная проблема, и очень мало причин не помещать ее в базу данных.

Однако мне нужно немного догадаться о том, чего вы пытаетесь достичь здесь. У вас есть онлайн-опрос, поэтому я предполагаю, что он будет использоваться более чем одним человеком. Ваша база данных должна будет приспособиться к этому, имея таблицу session или user, я выберу последнюю, так как она более понятна для чтения.

Во-вторых, у вас есть список locations (Сидней, Нью-Йорк, Лондон). Я предполагаю, что этот список может меняться со временем или даже от одного вопросника к другому.

Тогда у вас есть набор questions. Вы прямо не указываете, что они будут переменными или фиксированными. Поскольку вы разработали для этого набор таблиц, я предполагаю, что он должен быть переменным. Обратите внимание, что ваши вопросы представляют собой не матрицу, а список. Даже если они иерархичны, они все равно не составляют матрицы.

Наконец, что не менее важно, у вас есть ответы на эти вопросы.

Давайте создадим таблицу users:

user_id  user_name  
1        me
2        somebody else

Вторая таблица такая же простая: locations

location_id    location_name
1              Sidney
2              New York
3              London

Третья таблица немного сложнее - и, честно говоря, просто уродлива. Но это то, что вы получаете, если проектируете базу данных в базе данных, и альтернативы (использование DDL или хранение этой информации в XML/JSON или даже вне базы данных) также не очень хороши. Если есть иерархический вопрос (в ваших примерах они не показаны), вы можете добавить столбец «parent_question_id».

question_id    question_text      question_type    question_type_info
1              How do you rate    RADIO            0 to 5
2              Length of stay     COMBOBOX         1 day, 2 days, whatever
3              Visited last year  CHECKBOX         

Наконец, вам нужна четвертая таблица для хранения всех ответов.

user_id    location_id     question_id     value
1          1               1               2          <-- value here means "rating of 2"
1          1               2               5          <-- value here means "5 days"
1          1               3               1          <-- value here means "yes, visited last year"

Ага. некрасиво же. Если бы у вас был фиксированный список вопросов, я мог бы предоставить вам красивую базу данных :)

Изменить: Ответы на ваши комментарии. Чтобы связать ваши вопросы с опросом, вам понадобятся еще несколько таблиц, surveys определяющих, какие вопросы и для каких местоположений будут заданы. Следующий макет базы данных позволяет указать список местоположений и список задаваемых вопросов, а также название опроса.

Таблица surveys:

survey_id survey_name
1         Spring 2013 London Travel Survey
2         Spring 2013 Northern Hemisphere Short Survey

Таблица survey_questions:

survey_id question_id
1         1
1         2
1         3
2         1

Таблица survey_locations:

survey_id location_id
1         1
2         1
2         2

Содержимое, которое я помещаю сюда, дает вам два опроса. В опросе № 1 все три вопроса будут заданы только в одном месте: «Лондон». В опросе № 2 будет задан только один вопрос о Лондоне и Нью-Йорке. Если вы хотите задавать разные вопросы в разных местах, ваш макет таблицы должен будет приспособиться к этому, но такая система не будет вписываться в ваш исходный макет, похожий на таблицу.

Сделав что-то подобное, я бы порекомендовал рассмотреть возможность не превращать это в реляционную проблему. Что, если у вас есть объекты, и вы просто сериализуете их во что-то вроде JSON и сохраняете это?

Делая это реляционно, вы в конечном итоге потратите довольно много времени на создание таблиц и соединение сложного кода рисования в своем приложении, чтобы убедиться, что вопросы/ответы отображаются в правильном порядке и т. д.

В противном случае, я думаю, вы можете заставить свой подход работать. Не существует серебряной пули для разработки материалов для опросов в РСУБД.