Структура переменной в таблице БД для чтения в веб-форме - PullRequest
1 голос
/ 20 декабря 2011

У меня есть «переменная» структура, которая будет помещена в таблицу DB. Под «переменной» я подразумеваю последовательность пар «поле / значение», в которой «вид» поля определяет тип значения, я точно не знаю порядок полей и не знаю, сколько раз поля могут повторяться. Иногда группа полей повторяется несколько раз (это фискальная модель).

Дополнительное требование: я должен отобразить эти переменные данные в формы веб-страницы, обрабатывая некоторые работы CRUD. JQuery-UI, Struts 2, Hibernate. Предпочтительная СУБД: MySQL.

Решения, о которых я подумал:

  1. вертикальный стол. У меня могут возникнуть проблемы с производительностью, которые я мог бы решить с помощью материализованных представлений, которые «поворачивают» строки в столбцах, когда мне требуется массивный процесс обработки данных. Не зашло так далеко в этом направлении, поскольку оно кажется очень дорогим для разработки.
  2. Поля больших объектов. Упакуйте мои столбцы в один из них, возможно, с таблицей «сопоставления» для декодирования каждого столбца. Моя идея состоит в том, чтобы выдвигать доступные для поиска поля как «настоящие» столбцы, чтобы оставить в LOB только менее интересную группу данных и не создавать проблем с производительностью.
  3. или лучше 2a. Используйте xml внутри поля LOB. Это может быть полезно для более удобной упаковки / распаковки данных, особенно для отображения данных в веб-форму.

Что ты думаешь? И еще, есть ли способ создания автоматических представлений из полей XML? Или лучше сопоставить такие данные с веб-формой? Я подозреваю, что Hibernate Tools не будет работать ни в одном из описанных мной случаев.

Надеюсь, я все понял, это все еще немного сбивает с толку даже меня:)

1 Ответ

0 голосов
/ 20 декабря 2011

Ваш вариант 1 - антипаттерн Entity-Attribute-Value .

См. Мой ответ на Таблица продуктов, многие виды продуктов, каждый продукт имеет много параметров и мое сообщение в блоге EAV FAIL для альтернатив и некоторых причин, почему EAV не так, по крайней мере для реляционной базы данных (в моей книге я рассмотрю EAV, Антипаттерны SQL: предотвращение ловушек программирования баз данных ).

Также прочитайте эту статью о том, как подобная структура почти обречена на провал компании: Bad CaRMa .

Ваши опции 2 и 3 аналогичны описанным в Как FriendFeed использует MySQL для хранения данных без схемы . Я не знаю ни одного автоматического способа для ORM поддерживать эту структуру для вас. У вас есть работа по синхронизации ваших инвертированных таблиц индексов с данными больших объектов.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...