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

Question

[Quber]

Необходимо реализовать конструктор форм, например, из четырёх самых распространённых типов полей:

input
textarea
checkbox
radio

Формы можно создавать неограниченное количество и при большой посещаемости без проседаний в базе.

Мои мысли:
Создать таблицы

Forms // название формы, описание и т.п., связана с Options
Options // Храним названия полей + связь с forms и типами полей
Inputs
Textareas 
Checkboxes
Radios

Соответственно при выводе выбирать это всё из базы, собирать и выводить на экран.

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

UPD.
Коллега подсказал, что в таблицах

Inputs
Textareas 
Checkboxes
Radios

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

Comments

[Алексей Немиро]

Для элементов форм проще будет одну таблицу использовать, на основе которой будут формироваться формы.

Структура примерно такая:
id - идентификатор элемента
id_forms - идентификатор формы
element_type - тип элемента. Либо число, либо текст. Например, текст: input, textarea, radio
is_required - обязательное или нет
+можно добавить сообщения об ошибках, шаблоны для проверок введенных значений, атрибуты элемента и т.п.
Для свойств (тип элемента, is_required, тексты сообщений, атрибуты и т.п.) можно, в принципе, использовать отдельную таблицу, чтобы горизонтально сильно не растягивать.
Можно пойти еще дальше, и вынести некоторые данные в отдельные таблицы. Например, сообщения об ошибках и использовать идентификатор сообщения при описании элемента.
Или напротив, использовать одну таблицу для элементов, а структуру/поведение описывать в xml (годится только для малых объемов). Или, например, html-атрибуты или стили можно хранить строкой, как есть, на выходе вставляя в форму без дополнительной обработки.
Все зависит от деталей задачи, методов работы с данными и возможностей сервера.

Для значений - отдельная таблица. Можно все в кучу складировать, в nvarchar(max):
id_element - идентификатор элемента формы
value - сохраненное значение
Или разбить по типам данных. Тоже зависит от методов работы, возможностей сервера, предполагаемого количества данных и числа запросов.

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

Если количество данных будет исчисляться миллионами (объем гигабайтами), то лучше разбивать на мелкие части, чтобы база не пухла и не замедлялась сильно. Но требования к ресурсам сервера в любом случае будут выше. Если избыточно измельчить, то работать может медленней, чем могло бы. Тут нужно смотреть, как будет лучше, чем можно пожертвовать и что важнее.

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

Если данных будет миллионы миллионов, то по оптимизации:
- аккуратно строить структуру данных вертикально, не переборщить с измельчением;
- запросы лучше делать без всяких JOIN, отдельные SELECT FROM будут быстрее;
- етитегофреймфорк (Entity Framework), и прочие, на выходе лучше не использовать, LINQ не злоупотреблять;
- использовать индексы и делать это аккуратно. При неправильном использовании все можно так тормознуть, что ого-го :-)
- кэшировать данные, как минимум схемы форм;
- при сильном измельчении, строить "горизонтальный кэш" (лучше не силами СУБД, а брать сырые данные и готовить их программно силами C# или VB, это будет быстрее).

Это касается SQL Server.

[Quber]

Алексей Немиро: посещаемость около 1 млн чел, с помощью конструктора необходимо будет создать порядка 20000 форм. Есть несколько выделенных серверов, которые используют разные базы. таблицы можно выносить хоть по отдельности. Но вопрос оптимизации здесь стоит в первую очередь. Данных будет очень много поступать. Поэтому я и думаю как лучше организовать структуру базы.
Спасибо за ответ. Если есть что дополнить, с удовольствием почитаю.
Кстати, как Вам идея реализации, которая описана у меня вначале поста? Будут с ней проблемы? Что добавить или убрать из неё можно?

Answer 1

[DeFacto]

хранить в виде JSON и не усложнять