Какова наилучшая реализация создаваемых и изменяемых клиентом веб-форм в реляционной базе данных?

Question

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

Я видел, как это делается двумя способами:

1. Предполагая, что клиент только определяет, сколько полей и какие метки связаны с этими полями;мы можем прийти к решению, включающему четыре таблицы. FormDefinition, FormFieldDefinition, FormInstances, FormFieldValues.Клиент вносит изменения в FormDefinition и FormFieldDefinition, и веб-приложение использует эту информацию для отображения веб-формы HTML, в которой посетитель веб-сайта (конечный пользователь) отправит форму, в которой новая строка в FormInstances создается, и значения сохраняются в FormFieldValues стол.

   Строки в FormDefinition определяет форму, т.е. form definition ID = 2, form title = 'Car Registration Form'.Строки в FormFieldDefinition определяет поля формы в FormDefinition, т.е. field definition ID = 7, field label = 'Car Model', field type = 'varchar(50)'.Строки в FormInstance является экземпляром каждой формы, заполненной пользователем, т.е. definition id = 2, date_entered = '2008-09-24'.И ряды в FormFieldValues - это записи пользователя, т.е. field definition = 7, value = 'Tiburon'.

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

2. Альтернативой использованию четырех таблиц может быть сериализация определений форм и записей пользовательских форм в XML (или YAML или что-то подобное) и сохранение их в виде текста.Плюсом является то, что формы в базе данных удобочитаемы для человека.Обратной стороной является то, что при синтаксическом анализе XML потребуется больше накладных расходов приложения, а база данных станет гораздо менее доступной для запросов с точки зрения SQL.

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

Answer 1

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

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

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

Это может показаться дорогим или трудным для масштабирования.Вероятно, это правда.Поэтому реляционная база данных может быть не лучшим инструментом для этой работы.Вы упомянули возможность XML или YAML;по сути, это своего рода структурированный формат файла, который вы можете определить специально.Вам следует определить DTD для каждой формы клиента, чтобы каждую собранную форму можно было проверить.

редактировать: Если вам действительно нужна гибкость EAV в вашем приложении, ничего страшного, обычно есть обстоятельства, оправдывающие нарушение правил.Просто помните о дополнительной работе, которую необходимо выполнить, и запланируйте ее в своем графике разработки, а также при масштабировании своего сервера, чтобы он мог справиться с нагрузкой.Также смотрите другой мой ответ про EAV на StackOverflow.

Answer 2

как называется эта модель базы данных?

Не знаю, как это на самом деле назвать, но это тот же процесс, который используется при динамическом создании опросов.Если вы ищете какой-либо источник для создания приложений для опросов, вы найдете ту же общую схему базы данных, а также аналогичные методы.

Также обратите внимание на сайты конструкторов форм, например http://wufoo.com/ или http://frevvo.com/ для идей пользовательского интерфейса (если вы делаете его через Интернет).

Answer 3

Существует третий вариант: вы создаете таблицы и при необходимости добавляете столбцы.Это зависит от того, сколько форм создается, но базы данных могут легко обрабатывать большое количество таблиц.Поэтому, если пользователь хочет добавить форму «Форма регистрации автомобиля», вы добавляете таблицу «CarRegistrationForm».Для каждого поля, которое они хотят видеть в форме, вы можете позволить им выбирать между некоторыми базовыми типами, такими как дата, целое число и текст.И когда текст выбран, они должны ввести максимальную длину из списка выбора, который дает вам информацию, должно ли поле быть varchar или clob.

Это работает на SQL Server, где вы можете легко добавлять и удалять столбцы.Для DB2 это может быть проблемой, поскольку столбец удаления не реализован.Для MySQL я не уверен.

Вам все равно придется регистрировать формы и поля в них в двух отдельных таблицах.

Answer 4

Вы, вероятно, хотите Модель «сущность-связь»

Действительно, существуют инструменты с графическим интерфейсом для интерактивного создания схемы на основе таких моделей.