現在、MySQL には、さまざまな外部キー リンケージを持つ数十のテーブルを含む DB 構造があります。すべてのデータは、これからロードするファイル内にあるので、Drupal 7 で動作するストレージ システムに設計を移植できることを望んでいます。何かを簡単にセットアップできるからです (Feeds モジュールを使用しますか?)。 Drupal 7 が好む方法でデータを取得します。これの最終的な目的は、テーブルのエントリをリレーションでリンクし、場合によっては間違っているように見えるいくつかのフィールド データを修正するなど、多くの手作業による修正を行うことです。したがって、全体的な目標は、Drupal 7 でリレーションを表示および編集 (特に追加) するためのヒューマン インターフェイスを作成することです。問題は、データを保存する適切な方法は何かということです。そのため、必要なだけモジュール コードを記述しなければなりません。
このタスクを達成するには、次の 3 つのモジュールのいずれかを選択するように思われます。
- 関係
- エンティティ参照
- データ
Relation and Entity Reference を使用すると、すべてのデータを Drupal 7 のノード (エンティティ?) に格納できるようになるため、Drupal はすべてのものを処理するための「ネイティブ サポート」を持つことになります。ただし、数億から数十億のノードがあり、それぞれに他のノードとの関係が最大 3 つまであると予想しています。ビューなどで外部データを参照するとき (およびおそらくその参照から参照データを取得するときなど) に、リレーションまたはエンティティ参照はこれをどの程度効率的に処理しますか? ユーザーが設定できるようになるまで多くはnullになるため、null参照を持つノードをサポートできますか(したがって、特定のnull参照を持つノードを見つけるためのビューも必要です)?
データは別の可能性ですが、アルファ版であり、その安定性と効率について疑問があります。また、すべてのデータを Drupal ノードではなく外部の MySQL データベースに保存すると、そもそも Drupal を使用する目的全体が無効になるように思えます。これに対する私の感覚は正しいですか？
Drupal 7 が CMS であることを考えると、これは奇妙に思えます。ここで何かが欠けている必要がありますが、それが何であるかわかりません。この大量の相互に関連するデータを処理/インターフェースし、ユーザーが「テーブル」間のリンク (つまり「外部キー」) を主に設定および管理できるようにするための最も成熟したモジュールは何ですか? 」、おそらくフィールドデータのレビューと修正と一緒に？十分なものはありますか？