1

タグ スキーマに関してはかなりの議論がありますが、そのほとんどがブックマークや写真などの単一のコンテンツ タイプに焦点を当てていることに気付きました。

マルチテナント ビジネス アプリの複数の機能でタグを使用することに関心があります。タグがフォーム フィールド、ドキュメント、写真、構成設定などに関連している場合があります。

コンテンツ タイプごとにリンク テーブルを作成して複雑にするのではなく、これらのさまざまなニーズに合わせてスケーリングできる小さなテーブル セットを設計したいと考えています。

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

tagMap を使用して、これらのアイテムをいくつでも接続できますが、少なくともタグと tagType を接続します。たとえば、タグをドロップダウン フィールド タイプに関連付けることができます。これは、レジストリ タイプ、子値を持つレジストリ キーであり、エンティティに関連付けられている場合があります。複数レベルの親子関係を可能にするために、タグの子は別のタグである場合があります。

多くの機能が小さなテーブルセットに依存するようになるという点で、分散にはリスクがあります。

同様の決定に異議を唱えられた場合、または役立つアイデアがある場合は、考え、アプローチ、およびパフォーマンスが流通リスクにどのように関連しているかを共有してください.

ありがとう！

4

2 に答える 2

1

マークは良い点を持っていますが、複数のタグ テーブルと、タグ自体に固有の冗長性を避けたいとしましょう。我々は出来た：

**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 ... }

ここで、新しい問題が発生しました。タグ テーブルが非正規化されています。マークのシナリオと私自身のシナリオでは、テナントとクリエーターごとに複数のタグ名の生成、またはオーバーロードされたテナントとクリエーター フィールド (1 つのレコードに複数の ID) の生成を導入しました。

これを修正するには、次のことができます。

  • エンティティとユーザー コンテキストを TagMap テーブルにシフトし、3 つ以上のテーブルに結合します。コンテンツを配布したので、これは最初の投稿で説明したものよりも効率的だと思います。

    単一のタグ テーブルを作成します: Tags { TagsID, Name }

    テナントとユーザー テーブルの活用 Tenant { TenantID, Name, ... } Users { UserID, Name, ... }

    ドキュメント: TagMap_Documents { TagMap_DocumentsID, DocID, TagID, TenantID, CreatorID } Documents { DocID, Location/Blob, private(bit), ... }

    写真: TagMap_Photos { TagMap_PhotosID, PhotoID, TagID, TenantID, CreatorID } Photos { PhotoID, URL, PhotoBlob, private(bit), ... }

  • エンティティとユーザー コンテキストをコンテンツ テーブル (ドキュメント、写真) にシフトします。ここでの問題は、タグ自体がエンティティまたはユーザー固有のものではないため、自動補完/提案でノイズが発生する可能性があることです。

    単一のタグ テーブルを作成します: Tags { 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, private(bit), ... }

ここで特効薬を探すには、狩り全体よりも多くのことを考える必要があるかもしれません;) そうでなければ、とにかく、私たちは楽しんでいなかったでしょう :)

于 2009-08-21T20:39:03.043 に答える
0

テーブルが少ないほど効率が上がるとは思いません。コンテンツタイプごとに個別のテーブルを用意する方がよいのではないでしょうか。それはもっと読みやすいでしょう。カウントを取得するためのクエリも、JOINなどが少ないほど簡単で効率的ですか？

例えば：

ドキュメントの場合：

DocumentTags {ID TenantID Name CreatorID}

DocumentMappedTags {ID DocumentID DocumentTagID}

写真の場合：

PhotoTags {ID TenantID Name CreatorID}

PhotoMappedTags {ID PhotoID PhotoTagID}

于 2009-08-20T22:09:06.897 に答える