Проектирование баз данных для Меток нескольких типов объектов

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

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

Но если действительно необходимо искать все объекты всех типов с данным тегом, затем использование единственной таблицы "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');

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

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

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

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

- - - - - - - - - -
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: я никогда не пытался реализовать что-либо как это, таким образом, все мои рекомендации являются чисто теоретическими. Поэтому не стреляйте в меня, если я не вижу некоторых очевидных дефектов.:-)

В ответ на комментарий Bill Karwin:

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

1. Как я сказал, все зависит от требований. Если мы уверены это Taggable будет единственным "общим предком" объектов, затем это должно хорошо использовать Taggable_ID FKs как PKs для объектов. Но, например, что, если некоторые объекты, которые, оказывается, "taggable" также, должны быть "смотрибельными" (думают уведомления, расписания уведомления, и т.д.), или "безотносительно - способный" :-)? Мы можем сократить все те "способности" прочь путем связи какого-либо объекта трудно с Taggable?

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

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

- - - - - - - - - -
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)

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

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

Объект

• EntityId
• Имя:

Компонент

• EntityId
• Сумма

RecipeIssuer

• EntityId
• SomeOtherInformation

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

сделайте таблицы как нормальные для recipies, компонентов, и т.д.

затем Ваша таблица тега должна посмотреть это как это: идентификатор, Тип, Тег

Я рекомендовал бы использовать перечисление в коде для различения различных "Типов" (объекты).

Howabout это?

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

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

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

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

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

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

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

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

Теплоотводы являются просто примером простого продукта. Мы могли бы также поместить некоторые компьютерные части или одевающий в нашей базе данных. Это означает, что я должен смочь поместить различные 'теги' на два различных объекта, меня и A.

Я должен смочь реализовать поиск статей в интернет-магазине. Позволяет говорят, что я использую основанную на дереве навигацию, где у меня есть категория, названная "Используемые теплоотводы Ниссана". Поиск включил бы поиск и статьи и объекты, статьи имеют тег Model:Nissan, и объекты имеют тег Condition:Used., Конечно, когда пользователь посмотрит на статью, он будет действительно видеть все объекты, связанные со статьей.

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

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

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

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

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