我遇到了類似的問題,如 How to query abstract-class-based objects in Django? 該線程建議使用multi_table_inheritance。我個人認爲使用CONTENT_TYPE多個概念舒服(只是感覺更接近的邏輯,至少對我來說)Django:使用ContentType與multi_table_inheritance
使用上鍊接的例子,我想補充一個StelarType作爲
class StellarType(models.Model):
"""
Use ContentType so we have a single access to all types
"""
content_type = models.ForeignKey(ContentType)
object_id = models.PositiveIntegerField()
content_object = generic.GenericForeignKey('content_type', 'object_id')
然後添加此抽象示範基地
class StellarObject(BaseModel):
title = models.CharField(max_length=255)
description = models.TextField()
slug = models.SlugField(blank=True, null=True)
stellartype = generic.GenericForeignKey(StellarType)
class Meta:
abstract = True
要StellarObject和StellarType之間同步,我們可以連接post_save信號每次創建一個行星或恆星時間創建StellarType實例。通過這種方式,我可以通過StellarType查詢StellarObjects。 所以我想知道使用這種方法反對使用multi_table_inheritance的PRO和CON是什麼?我認爲在數據庫中都會創建一個額外的表格。但是數據庫性能呢?可用性/靈活性如何?感謝您的任何意見!
我對使用ContentTypes框架使用不相關的東西有同樣的感覺,但使用多表繼承時我感到有點不舒服。試圖在最佳實踐世界中引導,我在pydanny的書(2勺)中讀過多桌是邪惡的。最後一個問題是:效率還是優雅? – lborgav
我*愛*兩勺,但對多表繼承的一攬子告誡我真的不明白。您只需瞭解將爲您的應用程序生成的查詢以及它們是否代表問題。如果你可以在超類型表上完成大部分工作,那麼它特別沒有問題。從性能的角度來看,我無法想到爲什麼查詢超類型表並加入子類應該比爲通用ContentType表做同樣的事情更糟糕。我可以看到爲什麼你想避免一個真正複雜的類型層次,但... – acjay
我同意你的看法。並尋找一個很好的方式來處理這個我剛剛發現這個應用程序(django-model-utils),這似乎是非常有用的:[InheritanceManager](https://django-model-utils.readthedocs.org/en/ latest/managers.html) – lborgav