2

これはおそらく以前に尋ねられた質問ですが、私は自分のケースを正確に見つけるのに苦労しているので、フィードバックを求めて状況を説明します。

場所を登録するアプリケーションがあり、いくつかの種類の場所があり、場所の種類ごとに異なる属性セットがありますが、場所の種類や他の種類のコンテンツ (主にマルチメディア エントリやコメント) 上記のメモに。これを念頭に置いて、いくつかの解決策を思いつきました。

  1. ロケーションの種類ごとにテーブルを作成し、ロケーション テーブルごとに外部キーを持つ「メモ」テーブルを作成します。コメント テーブルごとにマルチメディアとコメントのテーブルを作成する必要があるため、これは非常に面倒です。たとえば、次のようになります。

    • 場所タイプA

      • ID
      • 属性1
      • 属性2

    • LocationTypeA_Notes

      • ID
      • 属性1
      • ...
      • LocationTypeA_fk

    • LocationTypeA_Notes_Multimedia

      • ID
      • 属性1
      • ...
      • LocationTypeA_Notes_fk

    などと面倒くさいのですが、やってしまえばこの構造での開発はさほど面倒ではないはずです。

  2. 次のように、場所とポイント コンテンツの一意の識別子を持つテーブルを作成します。

    • 位置

      • ID

    • 場所タイプA

      • ID
      • 属性1
      • 属性2
      • Location_fk

    • ノート

      • ID
      • 属性1
      • ...
      • Location_fk

    • マルチメディア

      • ID
      • 属性1
      • ...
      • Notes_fk

    ご覧のとおり、これははるかに単純で、開発も簡単ですが、ID のみのテーブルの外観が好きではありません (ええ、それは私がこれに対して持っている唯一の異議です。それは私が最も気に入っているオプションです。 、 実を言うと）。

  3. オプション 2 に似ていますが、次のような形の属性の膨大なテーブルがあります。

    • 位置

      • ID
      • タイプ

    • 属性

      • 名前
      • 価値

    など、または各属性のテーブル。Drupal風。これを開発するのは面倒です。場所に対して何かを行うには、いくつかの挿入/更新操作が必要であり、属性テーブルは場所テーブルよりも数倍大きくなる (または膨大な量の属性テーブルになる) ためです。サロゲートキーのみのテーブルにも同じ問題があります（プログラムで場所の動作を定義するために使用する「タイプ」があるだけです）が、それはかなりの解決策です。

では、パフォーマンスとスケーラビリティの点でどちらがより優れたソリューションになるかという質問に対して、どちらを採用しますか、またはどの代替案を提案しますか? これらの実装に問題はありません。オプション 2 と 3 は興味深い開発になるでしょう。そのようなことはしたことがありませんが、コンテンツが少し成長します。あなたはおそらく「Drupal が期待どおりに機能することがわかっているのに、なぜ Drupal を使用しないのですか?」と考えているでしょう。私は間違いなく専門家ではありません」.

また、これをすべて書いたので、オプション2は全体的に良い考えだと思いますか?エンティティをグループ化/継承をシミュレートするより良い方法を知っていますか? (「継承だけを使用してください!」とは言わないでください。MySQL の使用に制限されています)。

フィードバックをお寄せいただきありがとうございます。書きすぎて意味が少なすぎて申し訳ありません。

4

1 に答える 1