Как смоделировать «сетку» в базе данных?

Question

Я создаю вопросник для своего веб-сайта и хочу, чтобы один из типов ответов выглядел следующим образом:

[Question] How much did you like the food in:

[Answer]
        1    2    3    4    5
2006   [ ]  [ ]  [ ]  [x]  [ ]
2008   [ ]  [ ]  [x]  [ ]  [ ]
2010   [ ]  [ ]  [ ]  [x]  [ ]
2012   [ ]  [x]  [ ]  [ ]  [ ]

[Button] Save

теги [] должны быть радиокнопками, а каждый год должен быть 1группа radiobutton.

Мне нужно создать компонент, чтобы пользователь мог определить, сколько столбцов и строк должно иметь ответ на свой вопрос.Кроме того, пользователь должен иметь возможность указать текст для каждой строки и столбца.

Как мне смоделировать это в базе данных и связать вопрос с ответом?Как сохранить ответ как 1 ответ?

В настоящее время то, что я сделал, выглядит следующим образом:

[Table]Question

id (int)
question_wording (text)
question_number (varchar(50))
visible (int)


[Table]Multiple_Choice_Question
id (int)
choice_woring (varchar(200))
choice_number (varchar(50))

А затем у меня есть таблица перекрестных ссылок, чтобы связать вопрос с несколькими вариантами ответа,С этим решением мне нужно было бы создать вопрос для каждого года, например:

How much did you like the food in 2006?
How much did you like the food in 2008?

и связать его с вариантами ответов с вопросом через таблицу перекрестных ссылок.

ТакжеТаблица ответов выглядит следующим образом:

[Table]Answer
id (int)
question_number (FK)
choice_number (FK)

Вот изображение, иллюстрирующее сетку: http://imageshack.us/photo/my-images/857/capturedu.jpg/

Заранее спасибо !!

Answer 1

Я не понимаю требования «сохранить ответ как 1 ответ?».В реляционной модели это будет храниться в виде нескольких строк.Вот базовое определение данных:

Поскольку разные сетки должны быть возможны, я предлагаю определение строк и столбцов:

ROW_DEFINITIONS
- ID
- FORM_ID       - which form are we defining
- FIELD_NUMBER  - which field on the form is this
- ROW_NUMBER    - the row number of the grid
- DESCRIPTION   - the description of the row

COLUMN_DEFINITIONS
- ID
- FORM_ID
- FIELD_NUMBER
- COLUMN_NUMBER - the column number of the grid
- DESCRIPTION   - the description of the column

Затем зарегистрируйте ответы:

ANSWERS
- ID
- FORM_ID       - for which form is this answer
- USER          - who gave this answer
- ROW_NUMBER    - the row of the given answer
- COLUMN_NUMBER - the column of the given answer

Answer 2

«Как сохранить ответ как 1 ответить? "

Значение в типичной реляционной базе данных является монадическим, а не многозначным, и в вашем примере ответ имеет несколько значений, соответствующих каждому году. У вас есть два варианта для отслеживания данных по этому вопросу * s * (множественное число, а не этот вопрос, единственное число):

      How did you like the food in
          2006
          2008
          2010
          2012

1) Каждый год соответствует столбцу. Добавление новых годов требует добавления новых столбцов в таблицу.

или

2) Ответ каждого года соответствует записи о детях в отдельной таблице ОТВЕТОВ:

        QUESTION table (questionid, questiontext)
        ANSWERS table (id, questionid, answervalue)

, где в таблице ANSWERS может быть один или несколько ответов на один вопрос в таблице QUESTIONS - например, записи отдельных позиций в заявке. Вторая таблица в отношении «многие к одному» с первой - это то, как «нормализованная» реляционная база данных структурирует такие данные.

Приведенные выше определения таблиц просты и просты. Если бы я собирался отслеживать вопросы, состоящие из нескольких частей, я бы, вероятно, имел бы таблицу QUESTIONPARTS, которая связана с ВОПРОСАМИ, и связывал бы мою таблицу ANSWERS с QUESTIONPARTS, или использовал бы первый подход, когда обрабатывается каждая часть вопроса, состоящего из нескольких частей. как отдельный вопрос, который имеет свою колонку.

Проблемы уровня представления (GUI) не должны иметь ничего общего со структурой данных. Данные должны в конечном итоге быть пригодными для использования / запроса , и визуальный компонент, который вы разрабатываете для сбора информации, не определяет основную структуру данных.

Вы должны убедиться, что данные пригодны для использования, в противном случае сбор данных является пустой тратой времени для всех.

P.S. В последние годы объектная ориентация (поддержка пользовательских пользовательских структур) была привита к реляционным базам данных. Два крупных коммерческих игрока, Oracle и SQL Server, теперь поддерживают это, но они являются проприетарными расширениями стандарта SQL и не переносимы из одной системы в другую. И за много лет до этого базы данных, такие как PICK и его варианты, поддерживали многозначные значения. Несколько значений в столбце были отделены друг от друга с помощью определенных разделителей. Это часто называли «вложенной реляционной» моделью.