App Engineの多対多キーのリストプロパティ

Question

仮想の例として、TodoItemモデルとTodoListモデルがあります。 TodoListにはTodoItemの順序付きリストがあり、任意の1つのTodoItemは任意の数のTodoLists（多対多）に属します。 TodoList内のTodoItemの順序以外の関係については、他の情報を格納する必要はありません。これをデータストアで表現する最良の方法は何ですか？

これを実装するには2つの方法があります - todolistのクラスにTodoItemのを参照しますdb.KeyののListPropertyを与える：

class TodoList(db.Model): 
    items = db.ListProperty(db.Key) 

かも発注情報を含んでいるのListItemのモデルを作る：

class TodoListItem(db.Model): 
    item = db.ReferenceProperty(TodoItem) 
    list = db.ReferenceProperty(TodoList) 
    order = db.IntegerProperty() 

モデルを非正規化することによってこれを後で最適化することは間違いありませんが、事前最適化は、いずれかの表現が他の表現よりも利点を持っていますか？

Answer 1

これは、いくつかの要因に依存します。

• あなたはその順番以外の関係自体に関する情報を格納する必要がありますか？たとえば、多くの場合、注文と商品の間の多くが各商品の数量を保存する必要があります。
• 「小さい」カーディナリティ（例：> 1000 todoアイテム、またはアイテムの> 1000リスト）のように、関係の側に1000以上のアイテムを関連付ける必要がありますか？
• 通常、関連するすべてのアイテムを一度に取得したいのですか、またはそれ以上の選択をしたいですか？

アソシエーションに追加の情報が必要な場合、またはアソシエーション内に多数の要素がある場合、またはそれらのうちのいくつかを検索する必要がある場合は、おそらくリレーションエンティティが適しています。他の状況では、リストはより簡単で速くなります。 ToDoリストの場合、鍵のリストが最も確実に行く最善の方法だと私は言います。

Answer 2

別のTodoListItemの「リレーションクラス」は、正規化を推し進めているリレーショナルコンテキストを除いて（リレーショナルの場合は当然です）、別のTodoListItemの「リレーションクラス」は私にとって少し残虐なようですが、その問題についての一つの理由と、それがどのようにコード化するかということです。しかし、最適化すれば、アイテムがあるすべてのリストを簡単に見つけることができます。

Answer 3

TodoListItemが複数のTodoListsに属しているとすれば、アイテムが属する各リストに対して機能する単一の注文プロパティを持つことが有効であると懸念されます。私はItemがそれが属する各リストのOrderを必要とすると思います。