フィールドAPIとhook_schemaのフィールド

誰かが、hook_schemaで値として宣言するだけでなく、Fields APIを使用してエンティティのフィールドを作成する利点は何ですか？

定義されたすべてのフィールド、インスタンス、オプション、許可された値とデフォルト値などを取得するのは少し作業です。次に、ゲッターとセッターを処理する必要があり、最後にすべてをアンインストールするのはdb_deleteほど簡単ではありません。参照フィールドがある場合は特にそうです。他のエンティティによって使用されています。

カスタムテーブルのカスタムデータではなくフィールドを使用する最も重要な利点は、データがシステムの他の部分とすぐに統合されることです。含む（ただし、これらに限定されない）：

• ビューとの自動統合
• EntityFieldQuerys を使用する可能性
• 組み込みコードであっても、標準のシステムUIを使用してフィールドを管理できます
• 機能との自動統合
• フィールドのUIを拡張できる多くの提供されたウィジェットがあります（例：用語参照ツリーウィジェット）
• ロードフックでノード/エンティティにカスタムデータをロードする必要はありません、コアフィールドシステムがそれを行います
• データのCRUD操作を定義する必要はありません

きっともっとたくさんあると思います。

基本的に、追加データの操作/パフォーマンスをきめ細かく制御したい場合は、カスタムテーブルを使用します。これらすべてをシステムで処理する場合は、フィールドを使用します。最近では、ほとんどの場合、フィールドを使用してエンティティデータを格納しています。

Cliveの回答のコメントで述べたように、Entity APIのコントローラーの上にカスタムエンティティを構築すると、Cliveのポイントのほとんどが無効になります。CRUD、エンティティプロパティ*、エンティティのエクスポート、EFQサポート、ビューの統合を無料で簡単に行うことができます。また、データが単一のテーブルにあり、フィールド定義を持ち歩く必要がないため、パフォーマンスが向上します。

ただし、フィールドを使用する利点はまだいくつかあります。

• フィールドは、すべてのフィールドタイプの複数の値をサポートしています。
• さまざまな言語の値を保存でき、Entity翻訳モジュールでこのUIを取得できます。

• エンティティにフィールドを追加できるフィールドUI。したがって、再利用可能なエンティティの場合は、自分でフィールドを追加しなくても、それをフィールド可能にすることができます。

• スキーマに基づいて生成されるため、おそらくそれらを少し調整し、適切なタイプ（ブール値、intではなく日付など）を追加する必要があります。

BerdirとCliveは完全に正しいです。

実際には、フィールドを使用しない理由はデータベースのパフォーマンスだけでした。フィールドの書き込み/更新ごとに2つのINSERTステートメントが発生します。50個のフィールドがあり、node_save（）を実行すると、100個のINSERTがトリガーされます。

数千のノードがあり、1時間に数回ノードに書き込む場合、これは重要ではないことに注意してください。ただし、バッチで1,000万ノードを更新することは別の話です。このような状況では、berdirが言及したようにEntity APIのコントローラーの上に構築されたカスタムエンティティについて考えるか、MongoDBのような代替ストレージを検討する必要があります。