2 
class Account(models.Model):
        identifier = models.CharField(max_length=5)
        objects = MyCustomManager()

        class Meta:
            abstract = True

class Customer(Account):
        name = models.CharField(max_length=255)

多くのモデルがあり、どこにでも外部キーを置かなければならない時間を節約したい場合、これは正しいですか? それとも、私はこれをすべて間違って考えていますか？

4

2 に答える 2

1

この場合、アカウント ID を持つ顧客用の 1 つのテーブルがあり、Worker を追加すると、アカウント ID を持つ独自のテーブルが作成されます。

おそらく、アカウントと添付オブジェクトの顧客、従業員などを含む単一のテーブルが必要だと思いますか? これにより、アカウントを混同することはありません。

于 2010-01-25T22:52:16.127 に答える
1

外部キーがどちらの方向に向かうかによって異なります。抽象クラスへの外部キーを持つことはできません。

おそらく、あなたにとって興味深いのは一般的な関係であるか、抽象モデルクラスの外部キーです。

is-a通常の外部キーの使用は関係を意味しますが、継承は常に関係であることに注意してhas-aください。

あなたの例では、顧客がアカウントを持っているため、Customer継承しないでください。Account

継承の例は、レストランや映画館などの場所です。

コメント後に編集:

まあ、ドキュメントにはこれに関する独自のセクションがあります：

クラス継承とモデル マネージャーは、互いに完全に一致するわけではありません。多くの場合、マネージャーは定義されているクラスに固有であり、サブクラスでマネージャーを継承することは必ずしも良い考えではありません。また、最初に宣言されたマネージャーがデフォルトのマネージャーであるため、それを制御できるようにすることが重要です。したがって、Django がカスタム マネージャーとモデルの継承を処理する方法は次のとおりです。

...

  • 抽象基底クラスのマネージャは、Python の通常の名前解決順序を使用して、常に子クラスに継承されます (子クラスの名前は他のすべてをオーバーライドし、最初の親クラスの名前など)。抽象基本クラスは、その子クラスに共通する情報と動作をキャプチャするように設計されています。共通マネージャーの定義は、この共通情報の適切な部分です。
  • クラスの既定のマネージャーは、クラスで宣言された最初のマネージャー (存在する場合)、または親階層の最初の抽象基本クラスの既定のマネージャー (存在する場合) のいずれかです。デフォルト マネージャが明示的に宣言されていない場合、Django の通常のデフォルト マネージャが使用されます。

継承されたクラスが何らかの形で同じスコープに属している場合にのみ行います。
非常に多くのクラスがあり、これらのクラスに 1 行追加する必要がある場合は、DB またはアプリケーションの設計が適切でない可能性があります。

また、多くのクラスで 1 つのマネージャーのみを使用できるようにするためだけに、すべてを 1 つのマネージャーに配置しないようにしてください。

于 2010-01-25T22:52:28.473 に答える