Дизайн базы данных для маркировки нескольких типов сущностей

Я бы сказал, это зависит от того, как вы хотите использовать теги.

Я бы предположил, что вы могли бы создать дополнительную таблицу пересечений для каждого типа объекта, который хотите пометить, если вы ищите только один тип объекта за раз. Другими словами, было бы нормально сказать: «Покажи мне ингредиенты с тегом 'yummy'», но не совсем понятно, что это означало бы сказать: «Покажи мне ингредиенты и издателей рецептов с тегом 'yummy'». В этом случае можно иметь отдельную таблицу пересечений для каждого объекта.

Но если вам действительно нужно искать все сущности всех типов с заданным тегом, тогда проще использовать единую таблицу «ID». Сделайте так, чтобы все таблицы сущностей указывали на него с помощью столбца, который вы определяете как первичный ключ, так и внешний ключ:

CREATE TABLE Recipes (
  recipe_id INT NOT NULL PRIMARY KEY, -- not auto-generated
  FOREIGN KEY (recipe_id) REFERENCES Taggables(id)
);

Единственная слабость этого плана заключается в том, что вы не можете запретить строке в Recipes и Ingredients указывать на одну и ту же строку в Taggables.

INSERT INTO Taggables (id) VALUES (327);
INSERT INTO Recipes (recipe_id, name) VALUES (327, 'Hollandaise sauce');
INSERT INTO Ingredients (ingr_id, name) VALUES (327, 'eggs');

Вы хотите, чтобы каждый тег, связанный с яйцами, также относился к голландскому соусу?

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

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

Однако одна важная деталь в вашем дизайне остается для меня неоднозначной: если у вас будет что-то в этом роде

- - - - - - - - - -
Tag
    ID           // PK
    Name
    ...

- - - - - - - - - -
Taggable
    ID           // PK
    ...

- - - - - - - - - -
TagAssignment
    Tag_ID       // FK -> Tag.ID
    Taggable_ID  // FK -> Taggable.ID
    ...

- - - - - - - - - -
EntityOne
    Taggable_ID  // FK -> Taggable.ID
    ...

- - - - - - - - - -
EntityTwo
    Taggable_ID  // FK -> Taggable.ID
    ...

тогда будут ли у ваших классов сущностей свои собственные первичные ключи или вы собираетесь использовать EntityOne.TaggableID и EntityTwo.TaggableID в качестве первичных ключей де-факто для EntityOne и EntityTwo?

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

- - - - - - - - - -
EntityOne
    ID           // PK
    Taggable_ID  // FK -> Taggable.ID (Nullable)
    ...

- - - - - - - - - -
EntityTwo
    ID           // PK
    Taggable_ID  // FK -> Taggable.ID (Nullable)
    ...

Это не потребовало бы, чтобы каждая сущность имела соответствующий экземпляр Taggable, и, следовательно, это не потребовало бы, чтобы каждый фрагмент кода, связанный с сущностью, также знал о тегах. Однако, если тегирование будет действительно повсеместным в системе, и если вы уверены, что вам не понадобятся никакие другие «общие предки» для сущностей (то есть кроме Taggable), тогда вы можете обойтись без «внутренних» «Идентификаторы сущностей.

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

В ответ на комментарий Билла Карвина:

Вы правы: описанный выше дизайн не мешает нескольким объектам ссылаться на один и тот же Taggable. Но:

1. Как я уже сказал, все зависит от требований. Если мы уверены, что Taggable будет единственным «общим предком» сущностей, тогда можно использовать Taggable_ID FK в качестве PK для сущностей. Но, например, что, если некоторые объекты, которые могут быть "помечены", также должны быть "наблюдаемыми" (например, уведомления, расписания уведомлений и т. Д.) Или "что угодно" :-)? Можем ли мы отключить все эти «способности», жестко привязав любую сущность к Taggable?

2. Если вы действительно хотите, чтобы на уровне БД соблюдалось ограничение one-taggable-one-entity ... AFAIK, есть по крайней мере один общий способ сделать это, не заставляя FK выступать в качестве PK: путем введения "типов" тегов (которые в любом случае может быть полезен для некоторых других функций).

Что-то в этом роде позволит нам съесть торт и съесть его:

- - - - - - - - - -
Taggable
    ID           // PK
    Type        
    ... 
    - - - - - - - -
    Constraint: (ID, Type) is unique


- - - - - - - - - -
EntityOne
    ID
    Taggable_ID   
    Taggable_Type // Constraint: always = 'EntityOne'
    ...
    - - - - - - - -
    FK: (Taggable_ID, Taggable_Type) -> (Taggable.ID, Taggable.Type)

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

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

Сущность

• EntityId
• Имя

Ингредиент

• EntityId
• Количество

Рецепт

• EntityId
• SomeOtherInformation

Теперь у вас может быть таблица для пометки сущностей.

сделайте обычные таблицы для рецептов, ингредиентов и т. д.

тогда ваша таблица тегов должна выглядеть так: Id, Type, Tag

Я бы рекомендовал использовать перечисление в коде, чтобы различать разные «Типы» (сущности).

Как насчет этого?

Типы (PK: Тип, set_id [, TypeDesc])

Атрибуты (PK :( set_id, FK: Тип), значение)

PS: Полужирный / Курсив Realy Suck

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

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

Итак, у меня и А есть отношения N: M.

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

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

Радиаторы - это всего лишь пример простого изделия. Мы могли бы также добавить некоторые компьютерные детали или одежду в нашу базу данных. Это означает, что мне нужно иметь возможность ставить разные «теги» на два разных объекта, I и A.

Мне нужно реализовать поиск статей в интернет-магазине. Допустим, я использую древовидную навигацию, где у меня есть категория под названием «Подержанные радиаторы Nissan». Поиск будет включать поиск как статей, так и предметов, статьи имеют тег Model: Nissan, а предметы имеют тег Condition: Used. Конечно, когда пользователь просматривает статью, он действительно видит все элементы, связанные со статьей.

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

У нас есть элементы таблиц (I), статьи (A) и теги (T). Они объединены отношениями N: M: I2A соединяет элементы со статьями. T2I присоединяет теги к элементам и может также хранить значение тега или свойства. T2A присоединяет теги к статьям и может также хранить значение тега.

На бумаге этот дизайн с 6 таблицами для решения этой проблемы выглядит неплохо, но у меня возникает головная боль при формировании приличного запроса, где я могу выбрать статьи, соответствующие набору разных тегов и их значений, например: Condition = Remanufactured , Марка = Nissan

Я хочу иметь возможность делать что-то вроде www.summitracing.com. Выберите «Отделы» слева под «Магазином», выберите любую категорию, и вы увидите, как им удалось придать предметам некоторые свойства. У них есть размер двигателя для большинства применений, но при поиске колесных дисков у них также есть свойство ширины.

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