Итак, я пытаюсь создать базу данных, которая позволит мне подключить один продукт к нескольким категориям. Эта часть я понял. Но то, что я не могу решить, - это проблема хранения различных типов деталей.
Например, продукт может быть книгой (в этом случае мне нужны метаданные, которые относятся к этой книге, например isbn, author и т.д.), или это может быть бизнес-листинг (который имеет разные метаданные).
Как мне это решить?
Это называется шаблоном наблюдения.
alt text http://www.damirsystems.com/dp_images/observation_model_3.png
Три объекта, для примера
Book
Title = 'Gone with the Wind'
Author = 'Margaret Mitchell'
ISBN = '978-1416548898'
Cat
Name = 'Phoebe'
Color = 'Gray'
TailLength = 9 'inch'
Beer Bottle
Volume = 500 'ml'
Color = 'Green'
Вот как выглядят таблицы:
Entity
EntityID Name Description
1 'Book' 'To read'
2 'Cat' 'Fury cat'
3 'Beer Bottle' 'To ship beer in'
.
PropertyType
PropertyTypeID Name IsTrait Description
1 'Height' 'NO' 'For anything that has height'
2 'Width' 'NO' 'For anything that has width'
3 'Volume' 'NO' 'For things that can have volume'
4 'Title' 'YES' 'Some stuff has title'
5 'Author' 'YES' 'Things can be authored'
6 'Color' 'YES' 'Color of things'
7 'ISBN' 'YES' 'Books would need this'
8 'TailLength' 'NO' 'For stuff that has long tails'
9 'Name' 'YES' 'Name of things'
.
Property
PropertyID EntityID PropertyTypeID
1 1 4 -- book, title
2 1 5 -- book, author
3 1 7 -- book, isbn
4 2 9 -- cat, name
5 2 6 -- cat, color
6 2 8 -- cat, tail length
7 3 3 -- beer bottle, volume
8 3 6 -- beer bottle, color
.
Measurement
PropertyID Unit Value
6 'inch' 9 -- cat, tail length
7 'ml' 500 -- beer bottle, volume
.
Trait
PropertyID Value
1 'Gone with the Wind' -- book, title
2 'Margaret Mitchell' -- book, author
3 '978-1416548898' -- book, isbn
4 'Phoebe' -- cat, name
5 'Gray' -- cat, color
8 'Green' -- beer bottle, color
EDIT:
Jefferey поднял действительную точку (см. комментарий), поэтому я разберу ответ.
Модель позволяет динамически (на лету) создавать любое количество с любым типом свойств без изменений схемы. Hovewer, эта гибкость имеет цену - хранение и поиск медленнее и сложнее, чем в обычном настольном дизайне.
Время для примера, но во-первых, чтобы упростить задачу, я сглажу модель в виде.
create view vModel as
select
e.EntityId
, x.Name as PropertyName
, m.Value as MeasurementValue
, m.Unit
, t.Value as TraitValue
from Entity as e
join Property as p on p.EntityID = p.EntityID
join PropertyType as x on x.PropertyTypeId = p.PropertyTypeId
left join Measurement as m on m.PropertyId = p.PropertyId
left join Trait as t on t.PropertyId = p.PropertyId
;
Чтобы использовать пример Jefferey из комментария
with
q_00 as ( -- all books
select EntityID
from vModel
where PropertyName = 'object type'
and TraitValue = 'book'
),
q_01 as ( -- all US books
select EntityID
from vModel as a
join q_00 as b on b.EntityID = a.EntityID
where PropertyName = 'publisher country'
and TraitValue = 'US'
),
q_02 as ( -- all US books published in 2008
select EntityID
from vModel as a
join q_01 as b on b.EntityID = a.EntityID
where PropertyName = 'year published'
and MeasurementValue = 2008
),
q_03 as ( -- all US books published in 2008 not discontinued
select EntityID
from vModel as a
join q_02 as b on b.EntityID = a.EntityID
where PropertyName = 'is discontinued'
and TraitValue = 'no'
),
q_04 as ( -- all US books published in 2008 not discontinued that cost less than $50
select EntityID
from vModel as a
join q_03 as b on b.EntityID = a.EntityID
where PropertyName = 'price'
and MeasurementValue < 50
and MeasurementUnit = 'USD'
)
select
EntityID
, max(case PropertyName when 'title' than TraitValue else null end) as Title
, max(case PropertyName when 'ISBN' than TraitValue else null end) as ISBN
from vModel as a
join q_04 as b on b.EntityID = a.EntityID
group by EntityID ;
Сложно писать, но при ближайшем рассмотрении вы можете заметить шаблон в CTE.
Теперь предположим, что у нас есть стандартный фиксированный проект схемы, где каждое свойство объекта имеет свой собственный столбец. Запрос будет выглядеть примерно так:
select EntityID, Title, ISBN
from vModel
WHERE ObjectType = 'book'
and PublisherCountry = 'US'
and YearPublished = 2008
and IsDiscontinued = 'no'
and Price < 50
and Currency = 'USD'
;
Я не собирался отвечать, но сейчас принятый ответ имеет очень плохую идею. Реляционная база данных никогда не должна использоваться для хранения простых пар атрибут-значение. Это вызовет множество проблем в будущем.
Лучший способ справиться с этим - создать отдельную таблицу для каждого типа.
Product
-------
ProductId
Description
Price
(other attributes common to all products)
Book
----
ProductId (foreign key to Product.ProductId)
ISBN
Author
(other attributes related to books)
Electronics
-----------
ProductId (foreign key to Product.ProductId)
BatteriesRequired
etc.
Каждая строка каждой таблицы должна представлять собой предложение о реальном мире, а структура таблиц и их ограничений должны отражать реалии, которые представляются. Чем ближе вы сможете достичь этого идеала, тем чище будут данные, и тем легче будет делать отчетность и расширять систему другими способами. Он также будет работать более эффективно.
Вы можете использовать метод без схемы:
Удерживайте метаданные в столбце TEXT как объект JSON (или другую сериализацию, но JSON лучше объясняет причины).
Преимущества этой техники:
Меньше запросов: вы получаете всю информацию в одном запросе, не нуждаетесь в "направленных" запросах (для получения мета-метаданных) и присоединяетесь.
Вы можете добавлять/удалять любые атрибуты, которые вы хотите в любое время, не нужно изменять таблицу (что является проблемой в некоторых базах данных, например, Mysql блокирует таблицу и занимает много времени с огромными таблицами)
Поскольку это JSON, вам не нужна дополнительная обработка на вашем сервере. Ваша веб-страница (я предполагаю, что это веб-приложение) просто читает JSON, как есть, из вашего веб-сервиса, и что вы можете использовать JSON-объект с javascript, как вам нравится.
Проблемы:
Потенциально потраченное впустую пространство, если у вас есть 100 книг с тем же автором, таблица авторов со всеми книгами, имеющими только author_id, является более экономичным пространством.
Необходимо реализовать индексы. поскольку ваши метаданные являются объектами JSON, у вас нет индексов сразу. Но довольно просто реализовать конкретный индекс для конкретных метаданных, которые вам нужны. например, вы хотите индексировать по автору, поэтому вы создаете таблицу author_idx с author_id и item_id, когда кто-то ищет автора, вы можете искать эту таблицу и сами элементы.
В зависимости от масштаба это может быть излишним. при меньшем масштабе соединения будут работать нормально.
Продукт должен быть напечатан. например include type_id в таблице продуктов, которая указывает на категории продуктов, которые вы будете поддерживать, и позволяет узнать, какие другие таблицы запрашивать для соответствующих связанных атрибутов.
В этой проблеме у вас есть три варианта:
Это работает, когда объекты реального мира обрабатываются одинаково, по крайней мере, по большей части, и поэтому должны иметь, если не "те же" данные, по крайней мере, аналитические данные. Это разрушается при наличии реальных функциональных различий. Например, если для тостеров мы вычисляем ватты = вольт * усилители, вполне вероятно, что для книг нет соответствующего расчета. Когда вы начинаете создавать поля pages_volts, содержащие количество страниц для книг и напряжение для тостеров, все вышло из-под контроля.
Используйте схему свойств/значений, такую как Дамир. Смотрите мой комментарий к его сообщению за плюсы и минусы там.
То, что я обычно предлагаю, это схема типа/подтипа. Создайте таблицу для "продукта", которая содержит код типа и общие поля. Затем для каждого из настоящих типов - книг, тостеров, кошек и т.д. - создайте отдельную таблицу, связанную с таблицей продуктов. Затем, когда вам нужно выполнить обработку, специфичную для книги, обработайте таблицу книг. Когда вам нужно выполнить общую обработку, обработайте таблицу продуктов.