web-dev-qa-db-ja.com

オブジェクトにタグを実装する

私のアプリでは、アンケートシステムを実装しています。質問のタグを実装したいと思います。質問のタグやスタックオーバーフローとよく似ています。

これをオブジェクトのプロパティとして実装する方法についてアドバイスを受けたかったのです。それらは文字列の配列である必要があります-以下のように？

{
  "id": 123,
  "question": "What is your favorite color?",
  "tags": [
     "personality trait",
     "likes and dislikes"
  ]
}

それとも、実際の言い回しの代わりに、あるタイプの識別子を使用する方が良いでしょうか？

{
   "id": 123,
   "question": "What is your favorite color?",
   "tags": [1234, 89645]
}

これらの質問をNoSQLデータベースに保存することを考えており、ユーザーがこれらのタグに基づいてクエリを実行できるようにしたいと考えています。たとえば、誰かが「性格特性」に関するすべての質問を引き出したい場合、その特定のタグを含むクエリを実行できるはずです。

database-designdata-structuresnosqlmongodbdocument-databases
2
Sam

短い答え

これは、アプリケーションの観点から、タグをどのように処理するかによって異なります。それが単一のユーザー言語で検索するためだけのものであり、タグの正確さが重要でない場合は、文字列を探してください。しかし、他のすべてのケースでは、IDはIMHOのより良い候補になります。

詳細な回答

オプション1（文字列）では、タグはドキュメントに埋め込まれた単純な文字列値（別名値オブジェクト）と見なします。これには次のような影響があります。

  • 良い点は、オブジェクトに対応する必要なすべての値が単一のクエリで取得され、タグがクエリで非常に使いやすくなることです。
  • 多言語のタグ付け（つまり、各ユーザーが自分の言語でタグを使用する）は、残念ながらはるかにコストが高くなります。タグは単なる文字列であり、他の言語の他の文字列に関連付けるセマンティクスはありません。そのため、国際化の対象になる可能性がある場合は、このオプションを忘れてください。
  • 後でタグコレクションを作成して、短いタイトル、説明、タグの類義語（StackExchangeなど）などの追加情報でタグを充実させることができます。ただし、文字列で検索するタグドキュメントのクエリが必要になるため、使用するとコストが高くなります。 文字列インデックス は検索効率を高めることができますが、IDを介してアクセスすることはできません。
  • 文字列は、一般により多くのスペースを取ります。何百万ものタグがある場合、冗長データのためにかなりのスペースが無駄になります。
  • ユーザーにタグの完全なリストを表示するには、より多くの作業が必要になります（自動補完など）。したがって、タグ情報は信頼性が低くなるリスクがあります。

オプション2（id）では、タグは独立していると見なします エンティティ（DDDの意味で） MongoDBを使用しています- 埋め込みモデル の代わりに 正規化データモデル 。結果は次のとおりです。

  • 主な不便な点は、アプリケーションが reference を解決してタグ名を取得するために追加のクエリを使用する必要があることです。ただし、多言語タグが必要な場合、またはアプリケーションが他のタグ関連情報にアクセスする必要がある場合、これは実際のオーバーヘッドにはなりません。
  • 主な利点は、必要に応じてタグを充実させるために、タグドキュメントが既にあることです。
  • 参照を使用したタグドキュメントへのアクセスは非常に高速です（インデックスの間接参照を経由するよりも高速です）。
  • タグ付け情報はコンパクトです（ドキュメント参照は現在約12バイトです）。
  • タグ付けが頻繁に更新される場合、正規化されたモデルは、可変の成長する配列のパフォーマンスへの影響を回避します。
  • 独立したエンティティ間の 1対多の関係 を管理するように設計されたメカニズムを使用します。
  • タグ間の関係（同義語、包含など）を使用して複雑な検索を開発できます。

助言

個人的には、私が国際的な環境で働いているので、すぐにオプション2を選びます。問題は、オプション1から始めた場合、その後に進化するのが難しいことです。たとえば、スキルのタグ付けが最初に開始されたとき、LinkedInの誰かがdbモデルで文字列タグを使用したため、数年後、プロファイルを複数の言語で表示できますが、スキルタグは翻訳されていないため、英語でのみ使用できますまたは異なる言語を混合することによって。

4
Christophe