新しいコンテンツタイプを追加するよりも、エンティティを作成する方が適切なのはいつですか？

新しいコンテンツタイプを作成するだけでなく、新しいエンティティタイプを作成する利点は何ですか？

すべてのCRUDおよびビュー機能がコンテンツタイプに既に組み込まれている場合、新しいエンティティを作成するために必要なすべてのカスタムコーディングを行うのは少しやり過ぎです。

利点とは何であるかではなく、あなたが言ったような特定の状況に適切なものについてです。ノードでほとんど何でも表すことができ、99％の状況（少なくとも私が見つけたように）で、カスタムエンティティタイプを実装する必要はありません。

taxonomy_termエンティティタイプは、すべてがノード/コンテンツタイプである必要がない理由の良い例として常に考えています。

分類法の用語は、基本的に異なるエンティティをグループ化するためのものであり、ノードと同じ機能を必要としません。理論的にはコンテンツタイプを使用してこの機能を実行できます（ノード参照フィールドを使用する場合があります）が、分類用語はノードと同じことをする必要がないため、実際にはそうすることは意味がありません。同じことがのために言うことができるuserとtaxonomy_vocabulary、エンティティタイプ。

そのため、分類用語は別のエンティティとして作成され、必要なことだけを実行するようにプログラムされますが、フィールドを添付できるなどの利点は得られます。

簡単な答えは、ノード/コンテンツタイプが必要な処理を実行しない場合、または非常にわずかな利益のために大量の過剰/オーバーヘッドである場合、カスタムエンティティを記述することを選択することだと思います。

これは私の個人的な経験にのみ基づいています。Drupalのコア開発に直接関与している人がこれについて何と言っているか聞いてみたいです。

私が使用する非常に簡単な経験則は、コンテンツを単独で公開する必要があるかどうかです。その場合、ノードを選択し、そうでない場合はエンティティを選択します。Entityformsでは、エンティティに入力するためのインターフェイスを作成できるようになりました。

たとえば、D6で作成されたWebサイトでは、広告コンテンツタイプ（その画像フィールド、表示開始日/終了日...）を構築しますが、デフォルトでは公開せず、編集者に編集権限を付与する必要があります/ viewこれらのノードを表示し、views / searchがこれらを外の世界に表示しないことを望みます。それは非常に面倒であり、エンティティを扱う方が簡単です。

エンティティは、特定のユースケースを表します。

この単純な定義の功績はFagoにあると信じていますが、参照を見つけるのが面倒です。

必要に応じて、すべてのユースケースにContent（別名Nodes）を使用することもできますが、多くの場合、これは意味をなしません。

Content コメントとメニューの場所の両方の作成者と設定があります。

Usersは、上記のどちらも意味をなさないContentため、十分に異なるユースケースを表しますがuser、一方で、userメールとパスワードが必要です。

Taxonomy terms 彼らは、階層に配置される組み込み機能を持っているため、目立っています。

ユースケースが既存のエンティティと十分に類似している場合は、そのエンティティの使用に進みます。ただし、エンティティが既存のルールとは大幅に異なるルールによって管理されている場合は、新しいルールを作成します。

エンティティの紹介もありますが、残念ながらあなたの質問には答えられません。

コンテキストがすべてだと思います。ノードはブログ、記事、よくある質問などのコンテンツに主に使用されます。一方、スタッフ、顧客などのプロファイルのユーザー。新しいエンティティを作成する場合の例：

• フォーラム
• プロジェクト（プロジェクト管理の観点から）
• 形
• サポートチケット
• グループ

サポートチケットのようなものにノードを使用することもできますが、それは最良のテンプレートおよびデフォルトではないかもしれません...

エンティティは、ノードが持つすべての強力な機能を持つ必要がないため、ノードよりも少ないオーバーヘッドで作成できます。

また、ストレージをよりシンプルにできることも意味します。必要に応じて、JOINSを使用せずに単純なクエリですべての情報を取得するように構築できます。1つの整頓されたテーブルにすべてのフィールドがうまく配置されています。

これは、エンティティに対してクエリを実行する必要がある多くの関数があり、データベースへのUPDATEクエリと同時に多くのエンティティを更新している場合、大きなメリットになります。データが単一のテーブルに比較的自己完結していることを確認できれば、心配やデータ破損の可能性が少なくなります。

コンテンツタイプは、サイトコンテンツになるように設計されています。つまり、各コンテンツタイプは、サイトに公開されて表示されるように設計されています。たとえば、記事（箱から出して）は、最初のページに表示されるように設計されています。

ここで、雇用またはアパートの申請書のようなものを作成したいとします。明らかに、あなたのウェブサイトに誰かの雇用申請書を公開したくないでしょう。また、顧客/リードの連絡先のリストを作成したい場合はどうしますか？この情報が誤ってWebサイトに公開される可能性がありますか？個人的にはそうしません。

したがって、前述のエンティティフォームモジュール。コンテンツとして設計されていないエンティティタイプを作成できます。ただし、これらのエンティティタイプは、ルール、ビュー、オーガニックグループなどのエンティティをサポートするすべてのモジュールで使用できます。

そして、製品がエンティティタイプであるDrupal Commerceに入ります。基本的にエンティティを使用すると、開発者は元のDrupalデザイナーが予期しなかった方法でDrupalを拡張できます。

これは議論の対象となり、最終的には開発者として決定を下す必要があります。

データが独自のURLで公開されないようにするには、ノードよりもエンティティを選択します。デフォルトでは、ノードはURLエイリアス、公開ステータス、タイトル、メタタグなどを取得していますが、エンティティはデータベースのレコードを取得するだけです。

「できる限りテキスト付きのバナーを追加し、ブログポストでいずれかを選択できるようにしたい」

• コンテンツタイプは「ブログ」になります
• カスタムエンティティは「バナーアイテム」になります

エンティティとコンテンツ

エンティティには、 フィールドを持つエンティティバンドルがあります

コンテンツはエンティティの一種です。そう、

コンテンツには、フィールド（本文、記事画像）がある コンテンツバンドル（記事、ページ）があります

プログラマーであれば、独自のエンティティを作成するパスを選択することは確かですが、サイトビルダーにとっては最適なパスではない場合があります。再びサイトビルダーには、エンティティhttp://drupal.org/project/eckを作成するためのUIがあります