SOで使用されているようなタグシステムを実装する最善の方法は何だろうと思っていました。私はこれを考えていましたが、スケーラブルな優れたソリューションを思い付くことができません。
私は基本的な 3 テーブル ソリューションを考えていました:tagsテーブル、テーブル、articlesテーブルを持つことtag_to_articlesです。
これがこの問題に対する最善の解決策ですか、それとも代替手段はありますか? この方法を使用すると、時間の経過とともにテーブルが非常に大きくなり、これを検索するにはあまり効率的ではないと思います。一方、クエリが高速に実行されることはそれほど重要ではありません。
3 テーブル ソリューションに問題はありません。
もう 1 つのオプションは、記事に適用できるタグの数を制限し (SO では 5 つなど)、それらを記事テーブルに直接追加することです。
DB の正規化には利点と欠点があります。ちょうど 1 つのテーブルに物事を配線することには利点と欠点があります。
両方できないということはありません。情報を繰り返すことはリレーショナル DB パラダイムに反しますが、目標がパフォーマンスである場合は、パラダイムを破る必要があるかもしれません。
提案された 3 つのテーブルの実装は、タグ付けに使用できます。
ただし、スタック オーバーフローは別の実装を使用します。タグを posts テーブルの varchar 列にプレーン テキストで保存し、全文インデックスを使用してタグに一致する投稿を取得します。たとえばposts.tags = "algorithm system tagging best-practices"。ジェフがどこかでこれについて言及したと確信していますが、どこだったか忘れてしまいました。
提案されたソリューションは、タグと記事の間の多対多の関係に対処するために私が考えることができる唯一の実用的な方法ではないにしても、最善の方法です。したがって、私の投票は「はい、それでも最高です」です。ただし、代替案には興味があります。
データベースがインデックス可能な配列 (たとえば、PostgreSQL など) をサポートしている場合は、完全に非正規化されたソリューションをお勧めします。つまり、タグを文字列の配列として同じテーブルに格納します。そうでない場合は、オブジェクトをタグにマッピングするセカンダリ テーブルが最適なソリューションです。タグに対して追加の情報を保存する必要がある場合は、別のタグ テーブルを使用できますが、タグ ルックアップごとに 2 つ目の結合を導入しても意味がありません。