Модель данных для расширяемой веб-формы

Question

Предположим, у меня есть форма, которая содержит три 10 полей: field1..field10. Я храню данные формы в одной или нескольких таблицах базы данных, вероятно, используя 10 столбцов базы данных.

Теперь предположим, что через несколько месяцев я хочу добавить еще 3 поля. И в будущем я могу добавлять / удалять поля из этой формы в зависимости от меняющихся требований. Если у меня есть столбец базы данных для каждого поля формы, то мне придется вносить соответствующие изменения в базу данных каждый раз, когда я изменяю форму. Это похоже на головную боль обслуживания. Должен быть более изощренный способ.

Итак, мой вопрос: как мне спроектировать модель данных, которая слабо связана с моим пользовательским интерфейсом? Конкретный вариант использования - это система CRM, которая расширяема / настраивается пользователями.

Answer 1

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

Форма

ID
Имя
и т.д.

поле

ID
Этикетка
Значение

* 1015 поле формы * FormID
FieldID

Answer 2

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

Если вам абсолютно необходимо это сделать, то предложение Трэвиса подходит для небольших столов, но на самом деле оно не так хорошо масштабируется.

Answer 3

Я делал это в прошлом, используя столбец XML в базе данных для хранения дополнительных полей. У меня обычно есть большой набор свойств в столбце XML, а затем я использую XSD для принудительной проверки при обновлении или вставке. Когда я получаю данные, у меня есть правила в XSL или объектной модели, которые определяют, отображается ли элемент, какое дополнительное форматирование применить и для веб-форм, какой тип элемента ввода использовать на основе типа данных в узле свойства.

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

Если вам не нужно выполнять реляционные операции с данными, такие как объединение или вращение с другими таблицами в базе данных, тогда простая автономная форма XML также является хорошим решением.

Большинство баз данных теперь имеют первоклассную поддержку XML для такого рода вещей. Например, в SQL Server вы можете применить схему XSD к столбцу типа данных XML прямо в базе данных. В последних версиях также поддерживается индексация по этим столбцам.

Answer 4

Моя команда придумала решение для этого, когда я работал в Quest Computing на AIMS (www.totalaims.com). Таким образом, мы добавили экраны обслуживания, которые позволяли администратору добавлять метаданные, а также в результате добавлять поля в базу данных в определенных таблицах. Поля также были автоматически добавлены на собственные экраны обслуживания и поиска. Мы построили это поверх OpenACS. Вы можете узнать больше на www.openacs.org - поищите «flexbase» или «dynfields» или посмотрите здесь www.project-open.org/doc/intranet-dynfield/. Это сработало довольно хорошо - их основным недостатком является побочный эффект основного преимущества, то есть то, что добавление полей может выполняться не администраторами баз данных, и в результате производительность может быть легко скомпрометирована.