所以 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 }
利用租户和用户表
Tenant { TenantID, Name, ... } Users { UserID, Name, ... }
文档:
TagMap_Documents { TagMap_DocumentsID, DocID, TagID, TenantID, CreatorID } 文档 { DocID, Location/Blob, private(bit), ... }
照片:
TagMap_Photos { TagMap_PhotosID, PhotoID, TagID, TenantID, CreatorID } 照片 { PhotoID, URL, PhotoBlob, private(bit), ... }
将实体和用户上下文转移到内容表(文档、照片)。这里的问题是标签本身不是实体或用户特定的,这会在自动完成/建议中产生噪音。
创建单个标签表:
标签 { TagsID, Name }
文档:
TagMap_Documents { TagMap_DocumentsID, DocID, TagID } Documents { DocID, Location/Blob, TenantID, CreatorID, private(bit), ... }
照片:
TagMap_Photos { TagMap_PhotosID, PhotoID, TagID } 照片 { PhotoID, URL, PhotoBlob, TenantID, CreatorID, private(bit), ... }
在这里寻找灵丹妙药,可能需要比整个狩猎更多的思考;)如果不是,那么我们就不会有任何乐趣,无论如何:)