Как можно избежать дубликатов при хранении набора пар ключ-значение в СУБД в виде непрозрачной строки / большого двоичного объекта?

Question

Я пытаюсь решить, как мне хранить набор пар ключ-значение (строки) в БД.Классический подход выглядел бы примерно так, используя две таблицы:

  +-------------+
  | PropertySet |
  +-------------+
  | set_id      |
  | property_id |
  | value       |
  +-------------+

  +-------------+
  | Property    |
  +-------------+
  | property_id |
  | name        |
  +-------------+

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

  +-------------+
  | PropertySet |
  +-------------+
  | set_id      |
  | data        |
  +-------------+

Однако я хочу убедиться, что дубликатов нет.Я мог бы представить, как упорядочить набор по именам ключей, нормализовать формат и затем выполнить сравнение строк.Существуют ли альтернативы?

Я также ценю советы по актуальному вопросу проектирования (реляционная база данных против блобов), но, возможно, это следует упомянуть в комментариях.

Answer 1

Вот несколько мыслей по этому поводу:

• Как правило, столбцы BLOB-объектов будут работать медленнее, поскольку в большинстве баз данных они хранятся отдельно от данных таблиц.

• Вам понадобится ключ свойства, чтобы сформировать часть ключа базы данных для таблицы свойств, если вы хотите, чтобы база данных обеспечивала уникальность, поэтому вам понадобится структура, подобная таблицам Property / PropertySet, как описано в посте. чтобы получить ограничение целостности из базы данных.

• В любых, кроме тривиальных случаях вы, вероятно, не единственный, кто будет запрашивать базу данных. Кодирование данных в непрозрачных структурах значительно усложняет использование данных третьими лицами.

• Таблица набора свойств / свойств будет достаточно эффективной для запроса, особенно на платформе, которая поддерживает кластерные индексы.

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

Программная подборка набора свойств и сортировка его для выявления дубликатов кажется, по меньшей мере, такой же сложной, как запрос к объединенной структуре PropertySet / Property, поэтому я сомневаюсь, что вы действительно экономите свои усилия, выпрямляя его в любом случае. В любом случае требуется преобразовать его в структуру с парами ключ / значение - возможно, проще просто загрузить и сохранить их как таковые, и база данных станет намного более доступной для третьих сторон.

Answer 2

Я думал об этой проблеме раньше, но никогда не пытался найти решение, поэтому прими мое предложение с крошкой соли.

Что если вы сгенерируете хеш для данных, вы можете сохранить хеш в таблице в уникальном индексе.