Как создать базу данных для неизвестного количества "мета" - данных

Я хочу хранить определенные элементы в базе данных с переменным количеством свойств.

Например:

Элемент может иметь свойства " url " и "pdf", а другие не имеют свойств "image" и "location".

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

Как бы вы спроектировали эту базу данных. Как сделать ее доступной для поиска и эффективной?

Как будет выглядеть схема?

Спасибо!

9 2
database schema database-design entity-attribute-value

9 ответов:

То, что вы ищете, имеет имя - значение атрибута сущности (EAV). Это модель данных, которая используется в обстоятельствах, когда число атрибутов (свойств, параметров), которые могут быть использованы для описания вещи ("сущности" или "объекта"), потенциально очень велико, но число, которое фактически будет применяться к данной сущности, относительно скромно."

8

Если вы не обязательно привязаны к SQL, тройное хранилище предназначено именно для этой задачи. Большинство из них предназначены для запросов на языке запросов SPARQL.

2

Это звучит как идеальная работа для базы данных документов.

1

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

Пункт

ItemID

Наименование ...

Атрибуты

AttributeID

Атрибутивное описание ...

ItemAttributes

RowID

ItemID

AttributeID

Теперь, когда вы хотите сделать запрос, вы можете просто присоединиться к таблицам и фильтровать, как вы хотите...

0

Модель значения атрибута сущности (EAV) очень гибкая. Семантический веб и его язык запросов sparql также основаны на EAV. Но некоторым людям это не нравится, потому что с этой моделью есть штраф за производительность.

Начните с выполнения некоторых тестов высокой производительности нагрузки на базе данных. Не делайте их, когда закончите кодирование, потому что тогда будет слишком поздно.

Edit: сосредоточьтесь на скорости выполнения инструкций select. Пользователи ожидают быстрых результатов при поиске.

0

В прошлом я разрабатывал такие таблицы, чтобы они содержали следующие поля:

  1. id
  2. Тип
  3. подтип
  4. Значение

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

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

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

-1

Для такого рода сценариев я использую столбец типа XML в MS SQL 2005... вы будете иметь все преимущества XML + SQL. То есть использовать выражение XPath как часть SQL-оператора.

Это особенность MS SQL 2005, я не уверен, какие другие СУБД поддерживают это. Я не уверен в том, что это означает с точки зрения производительности.

-1

Создайте таблицу свойств со следующими полями:

Item_id int(или каков бы ни был тип идентификатора в таблице item) имя свойства varchar (500) property_value varchar (500)

Установите внешний ключ между item_id и полем id элемента, и все готово.

Вот как вы делаете отношение "многие к одному" в SQL.

-2

Выглядит как таблица " items "с первичным ключом" item_id", таблица" properties "с первичным ключом" property_id "и внешний ключ" item_id "с таблицей" items". "свойства "будут иметь столбцы" имя "и" значение", оба типа varchar.

Исполнитель? Не знаю.

-2