Как хранить объекты значений в реляционной базе данных?

Я работаю с большим проектом, в котором много объектов, представляющих простые (не связанные) значения. Иногда эти значения представляют собой одну строку, иногда две строки, иногда строку и int ...

В настоящее время у нас есть таблица «значений» в нашей реляционной базе данных, которая содержит столбцы: Id, Category, String1, String2 ..., Int1, Int2 ..., Double1 и т. Д. Это удобно, но беспорядочно.

Все значения обладают следующими свойствами:

  • Каждый объект с одинаковым Category имеет одинаковые атрибуты (т. Е. Типизирован).
  • Никакие объекты не связаны (единственный ключ - это Id первичный ключ).

Как нам выбраться из этого беспорядка? На мой взгляд, у нас есть следующие варианты:

  1. Просто продолжайте добавлять столбцы по мере необходимости и забудьте о семантическом сопоставлении между таблицей и объектом. Просто накапливайте это.
  2. Создайте новую таблицу для каждого объекта значения. Это добавит в базу данных большое количество таблиц, большинство из которых будет иметь менее 6 строк. Меня беспокоит шум, который все эти дополнительные таблицы добавляют в базу данных.
  3. Разверните базу данных без схемы только для этих объектов (на самом деле это невозможно в наших сценариях развертывания).
  4. Создайте таблицу с Id, Category столбцами и столбцом BLOB Value и сериализуйте объекты значений в столбец значений. Это жизнеспособно?

Этот пост повторяет наши параметры. Есть ли какие-либо недостатки или подводные камни при использовании сериализации? Есть ли вариант, о котором я не знаю? Совет приветствую.


serialization relational-database value-objects
person simonhaines    schedule 27.03.2013    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

Есть много причин и даже больше оправданий для денормализации базы данных. Производительность может быть наиболее важной, но сложность классификации данных (например, рассматриваемая проблема), безусловно, является самой распространенной. Более того, существует много способов денормализации базы данных, и многие из них решаются OP.

Однако факт в том, что базу данных следует денормализовать как последнее средство после того, как все остальное потерпело неудачу. Причины этого включают:

  • Данные становятся бессмысленными как для людей, так и для СУБД. Кому-то трудно понять или даже вспомнить назначение поля с именем Integer1 или сериализованного значения, которое потенциально может содержать что-либо. И СУБД не может извлекать значения из сериализованных сущностей для сортировки результатов или применения агрегатов.

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

  • Ограничения не могут быть применены, индексы не могут быть созданы. Нет смысла определять сериализованное поле как внешний ключ или ограничивать его определенным набором значений. Это отменяет большую часть механизмов самозащиты базы данных. Меньшая целостность данных означает больше административных затрат. Более того, здесь будет бесполезен и индекс, что сделает таблицу менее открытой для оптимизации.

  • Метаданные в конечном итоге придется хранить как данные. Представьте себе многоязычную CMS, в которой есть основная article таблица для хранения статей. Теперь для каждого поддерживаемого языка есть соответствующая таблица article_{lang} для хранения переводов (т.е. article_en, article_fr, article_es и т. Д.). Чтобы записать существующие переводы статей, должна быть создана таблица «отношений» с внешним ключом к таблице article, идентификатором языка, именем таблицы для таблицы перевода и полем, которое должно быть FK для перевода таблица , но не может быть определена как одна. Затем попробуйте написать запрос, который подсчитывает доступные переводы для каждой статьи!

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

person geomagas    schedule 29.10.2013