カスタムノード関連のデータはどこに保存すればよいですか？
私のウェブサイトがノードごとに生成するデータにはいくつかのタイプがあります。ノードの人気スコア、サードパーティのAPIから取得したノードのコメント数など...このデータはすべてのノードに設定されます。
以前は、各ノードに非表示フィールドを追加するだけでした。つまり、field_popularity_score、field_comment_count、etc ...、およびhook_cron;しかし、私は問題に遭遇しました。これらのフィールドが更新されるたびに、ノードの改訂日も変更されます。
このデータはどこに保存すればよいですか？標準のノードフィールドを使用しないでください。目的が損なわれるためです。
更新
どうやら この投稿 、Drupal 5を使用して、シリアル化されたデータを$node->data。
更新
興味深いことに、 Nodeオブジェクト参照 ページリスト$node->data Drupal 7.の一部として。Drupal 7。
データベースに独自のテーブルを作成することをお勧めします。他のモジュールと衝突する可能性が低い一意の名前をテーブルに付ける場合は、完全に許容できる方法です。
データベースAPI は、これに非常に役立つリソースです。
[編集：] J.レイノルズのおかげで、この場合は、必ず ビューについてテーブルに通知する が必要になります。
ノードを保存するときに$node->revision = FALSEを設定し、フィールドAPIを引き続き使用します。フィールドを使用することには多くの利点があり、モジュールを有効または無効にすると、フィールドをプログラムでスプールおよび破棄することができます（例についてはcommerce_priceを参照）。
利点は次のとおりです。
- 定義されたフィールドタイプの既存のテーブルスキーマを使用します。
- ディスプレイ管理ツール（DS、パネル、または「ディスプレイの管理」）と統合し、そのタイプのすべてのフィールドフォーマッタを備えています。
- UIは、必要な場合に使用できます。 #access => falseを設定するか、D8のフォーム表示を使用できます。
- より多くのモジュールがデータを認識して統合します（ビューは良い例です）。
- 維持する必要のあるカスタムコードがはるかに少なくなります。
- 時間を大幅に節約できます。
単純なコメント数または人気スコアの場合は、カスタムテーブルまたはエンティティAPIから十分離れている必要があります。
また、$entity->dataを使用することも災害のレシピです。データをフィルタリングまたはクエリできないことで、リレーショナルデータベースを使用する利点がほとんどなくなります。