私の質問は、タグを検索してフィルタリングできるようにタグを保存する最も効果的な方法は何ですか?
私の考えはこれです:
Table: Items
Columns: Item_ID, Title, Content
Table: Tags
Columns: Title, Item_ID
これは遅すぎますか?より良い方法はありますか?
私の質問は、タグを検索してフィルタリングできるようにタグを保存する最も効果的な方法は何ですか?
私の考えはこれです:
Table: Items
Columns: Item_ID, Title, Content
Table: Tags
Columns: Title, Item_ID
これは遅すぎますか?より良い方法はありますか?
1 つのアイテムに多くのタグが付けられます。そして、1 つのタグが多くのアイテムに属します。これは、多対多の障害を克服するために中間テーブルが必要になる可能性が非常に高いことを意味します。
何かのようなもの:
表: アイテム
列: Item_ID、Item_Title、Content
表: タグ
列: Tag_ID、Tag_Title
表: Items_Tags
列: Item_ID、Tag_ID
あなたの Web アプリは非常に人気があり、将来的には非正規化が必要になるかもしれませんが、早すぎる時期に水を濁しても意味がありません。
実際、規模によっては、tags テーブルを非正規化する方がより良い方法になると思います。
このように、タグ テーブルには単純に tagid、itemid、tagname が含まれます。
タグ名は重複しますが、特定のアイテムのタグの追加/削除/編集がより簡単になります。新しいタグを作成する必要はなく、古いタグの割り当てを削除して新しいタグを再割り当てします。タグ名を編集するだけです。
タグの一覧表示にはDISTINCTやGROUP BYを使うだけで、もちろんタグの使用回数も簡単にカウントできます。
質問で提供したデータに基づいて、遅さについて実際に話すことはできません。また、開発のこの段階では、パフォーマンスについてあまり心配する必要はないと思います。これは時期尚早の最適化と呼ばれます。
ただし、Tags テーブルに Tag_ID 列を含めることをお勧めします。通常、すべてのテーブルに ID 列を設定することをお勧めします。
タグとアイテムの間に多対多の関係があるため、タグ<=>アイテムの関連付けを格納するために中間の 3 番目のテーブルを使用することをお勧めします。つまり、1 つのアイテムを複数のタグに関連付け、1 つのタグを複数のアイテムに関連付けることができます。HTH、バルブ。
スペースが問題になる場合は、タグのテキストを格納する 3 番目のテーブル Tags(Tag_Id, Title) を用意してから、Tags テーブルを (Tag_Id, Item_Id) に変更します。これら 2 つの値は、一意の複合主キーも提供する必要があります。
アイテムには「ID」フィールドが必要であり、タグには「ID」フィールド (主キー、クラスター化) が必要です。
次に、ItemID/TagID の中間テーブルを作成し、そこに「完全なインデックス」を配置します。