0

、、または のUsersいずれかです。追加情報を格納するために、これらの各タイプのモデルがあります。さて、表に、私は持っているべきですかTypeSTypeCTypeAUsers

  1. タイプを指定する 3 つの null 許容外部キー フィールド
  2. 2 つのフィールド、1 つはタイプの名前、もう 1 つは外部キー
  3. 他のモデルの外部キーで型を指定する 1 フィールド
  4. ユーザーにフィールドがなく、逆の関係のチェックに依存していますか?

より洗練された回答を提供したい場合は、Django を使用しています。

4

3 に答える 3

4

Django はcontenttypes フレームワークの一部としてジェネリック リレーションを提供します。これにより、オプション #2 に似たものをより柔軟に実装できます。モデルに次のフィールドを追加することで、一般的な関係を確立できます。

content_type = models.ForeignKey(ContentType)
object_id = models.PositiveIntegerField()
content_object = generic.GenericForeignKey('content_type', 'object_id')

TypeSこのようにして、 、TypeC、またはのいずれかTypeAを問題の各ユーザーに割り当てることができます。TypeXまた、 aまたは aを追加する必要があるTypeY場合は、既に設定されているため、モデルを拡張する必要はありません。

于 2010-02-13T22:13:50.483 に答える
1

私自身、この状況に数回遭遇しました。私の個人的な好みはオプション 1 です (20 種類のユーザーがいる場合を除く)。

  • オプション 1 では、データベースの整合性を保証するための外部キー参照を作成するオプションが提供されます (3 つの列に制約があります)。

  • オプション 2 これは実際の外部キー参照ではありません。レコードがタイプ テーブルに存在しなくなりました。テーブル結合は論外です。

  • オプション 3 はオプション 2 よりもさらに悪いもので、Type テーブルに移動する前に値を解釈する必要があります。

  • オプション 4 も可能ですが、型データを探すのに少し似ています。これにより、1 人のユーザーが複数のタイプ定義を持つことができます。

于 2010-02-13T21:46:43.530 に答える
1

オプション＃1、3のnull許容外部キーを使用します。オプション #2、#3、および #4 では使用できない、実際のデータベースの外部キー関係を使用できます。そのため、次のようになります。

  • 追加情報のための最も簡単で最速のルックアップ
  • 無駄なディスク容量は最小限です
  • どちらの型であるかを判断するためのプログラミング ロジックは複雑ではありません (ただし、「2 フィールド」の可能性がある場合よりも少し複雑になります)。

あなたの質問のパート2に関しては、ビジネス固有のフィールドを保持するために、別のテーブルへのnull可能な外部キーが1つあると思います。

編集: オプション #2 を検討する理由が 1 つあります...タイプの数が 3 から 10 または 100 に増加する可能性があると予想される場合、オプション #1 システムはますます面倒になります..

于 2010-02-13T21:48:35.087 に答える