Ключ-значение для метаданных/тегов в СУБД: эффективное хранилище

Question

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

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

Еще одна информация о фоновом режиме, записи будут INSERTed, но не UPDATEd. В конце концов они будут DELETEd (последовательно, в том же порядке, в который они были вставлены).

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

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

в принципе, что это лучший выбор учитывая эти варианты ?:

ВАРИАНТ 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) 

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

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

• Получить пункты, где значение для данного ключа начинается с «х»

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

Answer 1

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

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