我有一个模型Thing
,可以使用Thing
和PointyThing
等几种类型的TastyThing
进行子类化。我有第二个模型,Instance
与Thing
s一对多相关(一个Instance
可能是单个Thing
的类型,但会有给定Instance
的许多Thing
个。然后,Instance
与Player
相关联(每个instance
只有一个Player
但player
有许多Instance
s,并且有反馈Player
可以调用它的.inventory
属性来查看它拥有的内容。
一切都很好,但我也有一个模型Place
。我希望Place
拥有Instance
s的方式与Player
拥有instance
的方式相同。
最好是创建一个与Owner
模型相关联的Instance
模型,然后进行子类化以获取Player
s和Place
s或其中一些未知SQLAlchemy中我还不知道的方法?
答案 0 :(得分:2)
我认为你要求的best
解决方案取决于很多因素。
从技术上讲,如果我单独查看您的示例,此解决方案看起来像一个漂亮的下降 hack
,这可以避免创建另一个relationship
表。如果你永远不会查询多态支持,这可能会飞得很好。然而,它仍然是一个黑客。想象一下,稍后您使用更多的子类扩展您的Player
模型,并且您可能开始使用多态查询,并且您将始终要问自己"how will it impact my hack"?
。即使一切仍然可以正常工作(现在我无法提出会破坏你的逻辑的例子),你仍然需要小心。
但是让我们看一下这个黑客的好处是什么?我们保存在一个relationship
表中,但实际上您为Owner
模型引入了另一个表(我假设Concrete Table Inheritance),那么真正的收益是什么?
另一方面,我想知道你的Instance
表格实际上是不是ternary
关系?我假设Thing
的每个实例都存储在某些Place
中,并且可能属于Player
,因此它可能只是一个表格如下:
Instance[
ID primary_key,
Thing_ID (FK) NOT NULL,
Place_ID (FK) NOT NULL,
Person_ID (FK) NULL
]
请注意Person_ID
可以为空,因为我认为Thing的实例在分配之前可能不属于任何人。但可能是你的情况总是NOT NULL
。
希望这会有所帮助。很高兴了解您决定采用哪种方式以及原因。