关于标签架构有很多关于标签架构的讨论,但我注意到它大部分都集中在单一内容类型上,例如书签或照片。
我有兴趣在多租户业务应用的多个功能中使用标签;标签可以与表单字段,文档,照片,配置设置等相关联。
我想设计一组可以扩展到这些不同需求的较小的表,而不是为每种内容类型标记链接表,这会增加一些复杂性:
tags {
tagsID
tagName
}
tagChildren {
childID
childValue
}
tagType {
typeID
typeName
}
entity {
entityID
entityName
...
}
tagMap {
mapID
tagsID (FK)
childID (FK)
typeID (FK)
entityID (FK)
}
tagMap可用于连接任意数量的这些项目,但至少应至少连接标签和tagType。例如,标签可以与下拉字段类型相关联。它可以是具有注册表类型,子值并与实体关联的注册表项。标签子可能是另一个标签,以允许多级父子关系。
分发存在风险,因为许多功能都依赖于一小组表格。
如果您受到类似决定的质疑,或者您的想法有所帮助,请分享您的想法,方法以及绩效与分销风险的关系。
谢谢!
答案 0 :(得分:1)
因此Mark有一个很好的观点,但是我们要说我们要避免多个标签表,以及标签本身的固有冗余。我们可以:
**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 ... }
现在我们引入了一个新问题 - 标签表是非规范化的。在Mark的场景中,在我自己的场景中,我们已经为每个租户和创建者,或者重载的租户和创建者字段(单个记录中的多个ID)生成了多个标记名称。
要解决这个问题,我们可以:
将实体和用户上下文转移到TagMap表,并连接到三个以上的表。我认为这比我在最初的帖子中提出的更有效,因为我们已经分发了内容。
创建一个标签表: 标签{TagsID,Name}
利用租户和用户表 租户{TenantID,姓名,......} 用户{UserID,Name,...}
<强>文件:强> TagMap_Documents {TagMap_DocumentsID,DocID,TagID,TenantID,CreatorID} 文件{DocID,位置/ Blob,私人(位),...}
照片:强> TagMap_Photos {TagMap_PhotosID,PhotoID,TagID,TenantID,CreatorID} 照片{PhotoID,URL,PhotoBlob,私人(位),...}
将实体和用户上下文转移到内容表(文档,照片)。这里的问题是标签本身不是实体或用户特定的,这可能在自动完成/建议中产生噪音。
创建一个标签表: 标签{TagsID,Name}
<强>文件:强> TagMap_Documents {TagMap_DocumentsID,DocID,TagID} 文件{DocID,Location / Blob,TenantID,CreatorID,private(bit),...}
照片:强> TagMap_Photos {TagMap_PhotosID,PhotoID,TagID} 照片{PhotoID,URL,PhotoBlob,TenantID,CreatorID,私人(位),...}
在这里寻找银弹,可能需要比整个狩猎更多的思考;)如果不是那么我们就不会有任何乐趣了,无论如何:)
答案 1 :(得分:0)
我不相信拥有更少的牌桌可以提高效率。为每种内容类型设置单独的表是不是更好。它会更具可读性。获得计数的查询也会更容易,更有效,减少JOIN等?
例如:
对于文档:
DocumentTags {ID TenantID Name CreatorID}
DocumentMappedTags {ID DocumentID DocumentTagID}
对于照片:
PhotoTags {ID TenantID Name CreatorID}
PhotoMappedTags {ID PhotoID PhotoTagID}