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

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 должен быть типом символа максимально возможного размера, который ваш клиент может указать в веб-форме ... и когда определения форм изменяются, управление старыми данными становится сомнительным. Но пользовательские записи могут быть запрошены (я написал быстрый запрос , в котором перечислены пользовательские записи с идентификатором формы, который похож на другой сводный вопрос ).

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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