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

Question

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

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

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

Answer 1

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

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

Answer 2

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

Форма

ID
Имя
и т.д.

Поле

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

Поле формы

ФормИД
Идентификатор поля

Answer 3

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

Answer 4

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

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

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

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