web-dev-qa-db-ja.com

Django）を使用して抽象基本クラスへの外部キーを設定する

2つのクラスの共通属性を抽象基本クラスに分解しましたが、これらのクラスのいずれかを参照する必要がある別のモデルがあります。 ABCには実際にはデータベーステーブルがないため、ABCを参照することはできません。

次の例は私の問題を説明するはずです：

class Answer(models.Model):
    ovramt = models.ForeignKey("Ovramt")
    question = models.ForeignKey("Question")
    answer = models.CharField(max_length=3, choices=(("yes","yes"),("no","no") ("NA","N/A"))
    likelihood = models.IntegerField(choices=LIKELY_CHOICES)
    consequence = models.IntegerField(choices=CONSEQUENCE_CHOICES)

    class Meta:
        abstract = True

class Answer_A(Answer):
    resident = models.ForeignKey("Resident")
    def __unicode__(self):
        return u"%s - %s - %s" %(self.ovramt.ssa.name, self.resident, self.question)    

class Answer_B(Answer):
    def __unicode__(self):
        return u"%s - %s" %(self.ovramt.ssa.name, self.question)    

class Answer_Risk(models.Model):
    answer = models.ForeignKey("Answer")
    risk = models.CharField(max_length=200)

    def __unicode__(self):
        return self.risk

Answer_AとAnswer_Bは、Answer_Aが別のテーブルとのFK関係も必要とするという点でわずかに異なります。 Answer_Bは、後でいくつかの特定の属性を必要とする場合もあります。 Answer_Bをスーパークラスにし、Answer_Aサブクラスを作成するか、それを作成した場合でも、問題は発生します。

「リスク」は、Answer_AでもAnswer_Bでも同じです。サブタイプに関係なく、「回答」を参照する必要がある他のモデルもあります。これはどのように行うことができますか？サブタイプに関係なく、どのようにタイプを参照できますか？

更新：
結合操作を回避しようとしましたが、回避できないと思います。すべての「回答」で「居住者」への参照を持ち、必要に応じてそれを無効にすることは価値がありますか？それとも、それは非常に悪い習慣と見なされますか？

pythondjangoinheritancedjango-models
31
Josh Smeaton

私の直感は、基本クラスの抽象修飾子を削除することを提案することです。同じモデル構造が得られますが、Answerは独自のテーブルになります。これの欠点は、これらが大きなテーブルであるか、クエリが複雑な場合、それに対するクエリが著しく遅くなる可能性があることです。

または、モデルをそのままにして、ForeignKey to Answerを GenericForeignKey に置き換えることもできます。モデル継承の構文糖衣構文で失うものは、クエリ速度が少し向上します。

ForeignKey（または機能的に同じもの）によって抽象ベースモデルを参照することは不可能だと思います。

8
Daniel Naab