3

いくつかのタイプのlikeとThingでサブクラス化できるモデルがあります。私は2番目のモデルを持っています。これはsに1対多に関連しています（1つはシングルのタイプである可能性がありますが、特定のsは多数あります）。次に、sはbackrefを使用して（それぞれに1つありますが、aには多くのsがあります）関連付けられているため、はそのプロパティを呼び出して、所有しているものを確認できます。ThingPointyThingTastyThingInstanceThingInstanceThingInstanceThingInstancePlayerinstancePlayerplayerInstancePlayer.inventory

すべて順調ですが、モデルもありますPlace。を所有するのと同じように、sもPlaceを所有したいと思います。InstancePlayerinstance

Ownerモデルとリンクし、Instanceサブクラス化してPlayersとPlaces、またはSQLAlchemy内でまだ知らない未知のメソッドを取得するモデルを作成するのが最善でしょうか？

4

1 に答える 1

2

bestあなたが求めている解決策は多くの要因に依存する と思います。

技術的には、あなたの例を単独で見ると、このソリューションは、別のテーブルhackを作成することを回避するかなりの降下のように見えます。relationshipまた、ポリモーフィックサポートを使用してクエリを実行しない場合は、問題なく動作する可能性があります。しかし、それでもハックになります。Player後でモデルをさらにいくつかのサブクラスで拡張し、ポリモーフィッククエリの使用を開始する可能性があり、常に自分自身に問いかける必要があると想像してください"how will it impact my hack"?。そして、すべてがまだ正常に機能している場合でも（現時点では、ロジックを壊すような例を思い付くことができません）、注意する必要があります。
しかし、このハックの利点は何ですか？1つのテーブルを節約しrelationshipますが、実際には、モデルに別のテーブルを導入します（具体的なテーブル継承Ownerを想定しています））、それで、実際の利益は何ですか？

一方で、あなたのテーブルは実際には関係Instanceになってはいけないのではないかと思います。の各インスタンスはいくつかに格納されており、に属している可能性がternaryあると想定しているため、次のような1つのテーブルにすぎない可能性があります。ThingPlacePlayer

Instance[
    ID primary_key, 
    Thing_ID (FK) NOT NULL, 
    Place_ID (FK) NOT NULL, 
    Person_ID (FK) NULL
]

Person_IDThingのインスタンスは、割り当てられるまで誰にも属していない可能性があるため、null許容であることに注意してください。しかし、それは常にNOT NULLあなたの場合である可能性があります。

お役に立てれば。あなたがどちらの方向に行くことに決めたのか、そしてその理由を学ぶのは良いことです。

于 2012-05-03T11:44:30.637 に答える