Схемы мультитенантных тегов для распределенных типов контента - PullRequest
Новая
       32

Схемы мультитенантных тегов для распределенных типов контента

1 голос
/ 21 августа 2009

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

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

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

tags {
  tagsID
  tagName
}
tagChildren {
  childID
  childValue
}
tagType {
  typeID
  typeName
}
entity {
  entityID
  entityName
  ... 
}
tagMap {
  mapID  
  tagsID (FK)
  childID (FK)
  typeID (FK)
  entityID (FK)
}

TagMap может быть использован для подключения любого количества этих элементов, но как минимум соединит теги и tagType. Например, тег может быть связан с раскрывающимся типом поля. Это может быть раздел реестра с типом реестра, дочерним значением и связанный с объектом. Дочерний тег может быть другим тегом, чтобы разрешить многоуровневые родительско-дочерние отношения.

Существует риск распространения, поскольку многие функции зависят от небольшого набора таблиц.

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

Спасибо!

Ответы [ 2 ]

1 голос
/ 22 августа 2009

Итак, у Марка есть хорошая точка зрения, но, скажем, мы хотим избежать таблиц с несколькими тегами и избыточности, присущей самим тегам.мы могли бы: 

**Create a single Tags Table:**
  Tags { TagsID, TenantID, Name, CreatorID }    

**Documents:**
  TagMap_Documents { TagMap_DocumentsID, DocID, TagID }
  Documents { DocID, Location/Blob, ... }

**Photos:**
  TagMap_Photos { TagMap_PhotosID, PhotoID, TagID }
  Photos { PhotoID, URL, PhotoBlob ... }

Теперь мы ввели новую проблему - таблица тегов денормализована.В сценарии Марка и в моем собственном случае мы представили создание нескольких имен тегов для каждого владельца и создателя или перегруженных полей владельца и создателя (несколько идентификаторов в одной записи).

Чтобы это исправить, мы можем:

  • сместить сущность и пользовательский контекст в таблицы TagMap и присоединиться к более чем трем таблицам.Я думаю, что это будет более эффективно, чем то, что я изложил в своем первоначальном посте, потому что мы распространили контент.

    Создайте одну таблицу тегов: Теги {TagsID, Name}

    Использование таблиц Tenant и User Tenant {TenantID, Name, ...} Users {UserID, Name, ...}

    Документы: TagMap_Documents {TagMap_DocumentsID, DocID, TagID, TenantID, CreatorID} Документы {DocID, Местоположение / Blob, частный (бит), ...}

    Фото: TagMap_Photos {TagMap_PhotosID, PhotoID, TagID, TenantID, CreatorID} Фотографии {PhotoID, URL, PhotoBlob, private (бит), ...}

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

    Создать одну таблицу тегов: Теги {TagsID, Имя}

    Документы: TagMap_Documents {TagMap_DocumentsID, DocID, TagID} Документы {DocID,Местоположение / Blob, TenantID, CreatorID, частный (бит), ...}

    Фотографии: TagMap_Photos {TagMap_PhotosID, PhotoID, TagID} Фотографии {PhotoID, URL, PhotoBlob, TenantID, CreatorID, частный (немного), ...}

Чтобы найти здесь серебряную пулю, может потребоваться больше размышлений, чем всей охоты;) Если бы не было, мы бы не сталив любом случае, развлекаюсь:)

0 голосов
/ 21 августа 2009

Я не верю, что меньшее количество столов сделает вещи более эффективными. Разве не лучше просто иметь отдельные таблицы для каждого типа контента. Это было бы более читабельным. Запросы для подсчета также было бы проще и эффективнее, если бы было меньше СОЕДИНЕНИЙ и т. Д.

например:

Для документа:

DocumentTags {ID TenantID Имя CreatorID}

DocumentMappedTags {ID DocumentID DocumentTagID}

Для фотографий:

PhotoTags {ID TenantID Имя CreatorID}

PhotoMappedTags {ID PhotoID PhotoTagID}

...