Пары ключ-значение для метаданных / тегирования в СУБД: эффективное хранение - PullRequest
1 голос
/ 08 февраля 2011

Я знаю, что пары ключ-значение не являются хорошим дизайном базы данных, не нормализованы и т. Д. Однако в этом случае я считаю, что они являются наиболее подходящим решением.

Мой извините за это, инекоторый фон : большой набор элементов помещается в набор таблиц, и каждый элемент может быть помечен произвольными метаданными, которые может выбрать пользователь.Пользователь может выбрать метаданные, потому что он указывает, как он хочет классифицировать, отчитываться и просматривать элементы позже.Для этой конкретной бизнес-задачи не наше (как разработчики систем) сказать, что это за размеры.Не существует согласованного набора ключей, используемых в элементах, и в некоторых случаях наличие определенного ключа будет использоваться в качестве условия фильтра.

Еще один бит фоновой информации, записи будут вставлены, но не ОБНОВЛЕНЫ.В конце концов они будут УДАЛЕНЫ (последовательно, в том же порядке, в котором они были вставлены).

Вопрос "Эффективное хранение" : под этим я имею в виду производительность запроса (чтения).Будут использоваться следующие типы запросов:

  • Получить элементы с данным ключом, любое значение
  • Получить элементы с данным ключом и значением
  • Получить элементы свсе имена ключей
  • Получить элементы со всеми именами и значениями ключей

В основном, какой вариант является наилучшим при данных параметрах?:

ОПЦИЯ 1

Items table:
item_id (integer, pk)
... item fields ...

ItemFacts table:
item_id (integer, fk)
key_name (nvarchar(64))
key_value (nvarchar(128))

ВАРИАНТ 2

Items table:
item_id (integer, pk)
... item fields ...

Facts table:
fact_id (integer, pk)
key_name (nvarchar(64))
key_value (nvarchar(128))

ItemFacts table:
item_id (integer, fk)
fact_id (integer, fk)

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

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

  • Получить элементы, в которых значение для данного ключа начинается с 'x'

Если я могу дать какие-либо дополнительные пояснения,пожалуйста, дайте мне знать.

1 Ответ

2 голосов
/ 08 февраля 2011

Вам не нужен повод, чтобы сделать плохой дизайн.Ваш дизайн - ваш выбор.Но спросить, как лучше всего испортить мой дизайн, - это не вопрос с множеством ответов и без хороших.Реальный вопрос заключается в том, какую другую технологию хранения следует использовать INSTEAD СУБД.

Существуют системы, предназначенные для хранения данных со значением ключа, например Cassandra .Ищите NoSQL ... найдите подходящую технологию.

...