分類法とオプションリスト
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
タクソノミーやオプションリストのナビゲーションは、効果的なスキーマ管理の重要な要素です。この記事では、タクソノミーとオプションリストのどちらを選ぶかを説明し、ご自身のニーズに基づいた情報に基づいた選択をサポートします。また、これらの構造に名称を付ける際のベストプラクティスも示し、明確さと一貫性を確保しています。
タクソノミーとオプションリストのどちらを選ぶか
データモデルの設定には繰り返しの疑問がつきます: オプションリスト を使うべきか、それとも タクソノミーを使うべきか?必要な機能を備えた高性能なアプリケーションを実現するためには、適切なデータ形式を選ぶことが重要です。
このセクションには、データモデルでタクソノミーを使うタイミングやオプションリストを使うタイミングを判断するための推奨事項やガイダンスが含まれています。
以下の表を使って、タクソノミーとオプションリストのどちらかを選択してください。
前提条件
分類
オプションリスト
価値観はたくさんあります
50以上の値が豊富なリストがある場合に使われます。300以上の分類値を使わないようにしてください。これはパフォーマンスの問題を引き起こす可能性が高いためです。
50未満の値を持つ管理語彙リストがある場合に使われます。
値に基づいてセキュリティルールを設定する必要があります
タクソノミー値に基づくセキュリティモデルルールを適用するために使われました。例えば、 Fruitful ブランド承認者はFruitfulブランドの資産のみを承認でき、他の資産は承認できません。
セキュリティプロパティを含めません。値に基づくセキュリティルールが不要な場合に使用されます。
自分の価値観を受け継ぐ必要があります
検索ページにファセットを作成するために使われました。
データモデルのファミリーツリーから継承することはできません。例えば、 M.ProductFamily の定義にオプションリストがある場合、 Products 検索ページでファセットフィルターとして表示することはできません。
主要な数値だけでなく、もっと多くの情報を含める必要があります
スキーマ定義として記述などの追加のプロパティを保持することができます。
オプションリストは単純なデータソースなので、制御された語彙の値以上は保持できません。
5レベル以上の階層構造が必要です
彼らが運べる階層の数に制限はありません。
単純な5階層構造に限定されています。
エンティティ詳細ページとSearchコンポーネントにデータを表示する必要があります
エンティティ詳細ページおよび Search コンポーネントに表示されるデータに使用されます。
エンティティ自体にのみ表示されるデータに使用されます。
命名規則
スキーマやタクソノミーの命名が一貫して論理的かつ予測可能であれば、類似したスキーマやタクソノミーをより簡単に区別できます。Content Hubは、名前がMでつながるタクソノミー(例: M.entityDefinitionNameやM.TaxonomyName)を含む事前構築されたデータモデルを持っています。
データモデルを定義する際には、以下のことを推奨します。
- Content Hubプリビルドモデルと同様に、スキーマやタクソノミーにパーソナライズされた命名規則を定義し適用XYZ新しい分類法をXYZに付けることがあります。TaxonomyまたはXYZ。定義。
- 関係名を体系的に付けましょう。2つの定義間の関係を定義する際は、まず親エンティティの定義名を書きましょう。例えば、 Brand と Asset 定義を関連付けたい場合は、関係名を BrandToAssetにしてください。関係名にピリオドを使うのは避けましょう。
!注分類名は文字、ピリオド、下線のみを含めます。