Хранение вопросов таблицы с одной формой в 1 или нескольких таблицах

Question

Я давно кодирую формы ASP.NET внутри веб-приложений.Как правило, в большинстве веб-приложений есть пользователь, который входит в систему, выбирает форму для заполнения и отвечает на вопросы, чтобы ваша таблица выглядела следующим образом

Table: tblInspectionForm
Fields:
inspectionformid (either autoint or guid)
userid (user ID who entered it)
datestamp (added, modified, whatever)
Question1Answer: boolean (maybe a yes/no)
Question2Answer: int (maybe foreign key for sub table 1 with dropdown values)
Question3Answer: int (foreign key for sub table 2 with dropdown values)

Если я не ошибаюсь, она соответствует как второй, так и третьей нормальным формам.Вы не храните имена пользователей в таблицах, просто идентификаторы.Вы не сохраняете выпадающие значения или значения «да / нет» в Q-3, а просто идентификаторы других таблиц.

Однако ЕСЛИ все вопросы имеют одинаковый тип данных (предположим, что Q1 или Q1 также не являются целыми числами), которые ссылаются на один и тот же внешний ключ (например, форма, содержащая 20 вопросов, все по шкале от 1 до 10 или имеющие одинаковые ответы на выбор), было бы лучшесделать что-то вроде этого?

so .. Table: tblInspectionForm
userid (user ID who entered it)
datestamp (added, modified, whatever)
... and that's it for table 1 .. then

Table2: tblInspectionAnswers
inspectionformid (composite key that links back to table1 record)
userid (composite key that links back to table1 record)
datastamp  (composite key that links back to table1 record)
QuestionIDNumber: int (question 1, question 2, question3)
QuestionAnswer: int (foreign key)

Это не относится только к формам, которые имеют одинаковые типы ответов для одной формы.Может быть, ваша форма имеет 10 из этих 1-10 оценок (int), 10 булевых вопросов, а затем 10 произвольных. Вы можете разбить ее на три таблицы.

Недостатком будет то, что при сохраненииформа, вы делаете 1 звонок на каждый вопрос в вашей форме.Положительным моментом является то, что если у вас много ночных интеграций или репликаций, которые извлекают ваши данные, если вы решите добавить новый вопрос, вам не нужно вручную изменять какие-либо репликации для источников данных отчетов или что-либо еще, предназначенное для чтения./ запросить данные формы.Если у вас изначально было 20 вопросов, и вы внедрили в свое приложение изменение, добавляющее 21-е, оно автоматически будет включено во все внешние репликации, источники данных, отчеты, которые запрашивают эти данные.Другое преимущество состоит в том, что если у вас ДЕЙСТВИТЕЛЬНО ДОЛГО (это часто случается в сфере недвижимости, когда у вас есть формы проверки с сотнями вопросов, которые выходят за пределы 8 КБ для строки таблицы), вы не столкнетесь с проблемами.

Был бы такой сценарий когда-либо предпочтительным способом сохранения данных формы?

Answer 1

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

Answer 2

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

create table Forms
(
    id int identity(1,1) not null primary key,
    name varchar(100) not null, -- with a unique index
    -- other form related fields here
)
create table QuestionTypes
(
    id int identity(1,1) not null primary key,
    name varchar(100) not null, -- with a unique index
)

create table Questions
(
    id int identity(1,1) not null primary key,
    form_id int not null foreign key references Forms(id),
    type_id int not null foreign key references QuestionTypes(id),
    content varchar(1000)
)

create table Answers
(
    id int identity(1,1) not null primary key,
    question_id int not null foreign key references Questions(id),
    content varchar(1000)
    -- For quizez, unremark the next row:
    -- isCorrect bit not null
)

create table Results
{
    id int identity(1,1) not null primary key,
    form_id int not null foreign key references Forms(id)
    -- in case only registered users can fill the form, unremark the next row
    --user_id int not null foreign key references Users(id), 
}

create table UserAnswers
(
    result_id int not null foreign key references Results(id), 
    question_id int not null foreign key references Questions(id), 
    answer_id int not null foreign key references Answers(id),
    content varchar(1000) null -- for free text questions
)

Этот дизайн потребует нескольких соединений при создании форм (и если у вас есть несколько форм для приложения, вы просто добавляете таблицу приложения, на которую может ссылаться форма), и несколько объединений, чтобы получить результаты, но это лучший дизайн базы данных динамических форм, который я знаю.

Answer 3

Я не уверен, является ли он «предпочтительным», но я наверняка видел этот формат, используемый в коммерческих целях.

Вы могли бы потенциально сделать вспомогательную таблицу более гибкой с помощью нескольких столбцов ответов (answer_int, answer_varchar, answer_datetime) и назначить значение вопроса, к которому можно обратиться, чтобы получить ответ из правого столбца.

Таким образом, если q_var = 2, вы знаете, что смотрите в answer_varchar, тогда как q_value = 1, который вы знаете, является целым числом и требует поиска (имя которого также может быть указано в вопросе и сохранено в столбце).

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