物語：
お気に入りの映画に基づいて人々がお互いを検索できるサイトを作成しているとします。したがって、主な 2 つのエンティティとしてand がUserあります。お気に入りの映画の概念を関連付けて捉えるためのオプションMovieはほとんどありません。UsersMovies
最初:Movieキーのリストを作成します。User
モデルは次のようになります
class User(ndb.Model):
username = ndb.StringProperty()
userid = ndb.IntegerProperty()
email = ndb.StringProperty()
favorite_movies = ndb.KeyProperty(kind=Movie, repeated=True)
class Movie(ndb.Model):
title = ndb.StringProperty()
description = ndb.TextProperty()
2 番目: リレーションシップ用に別のエンティティを作成する
モデルは次のようになります
class User(ndb.Model):
username = ndb.StringProperty()
userid = ndb.IntegerProperty()
email = ndb.StringProperty()
class Movie(ndb.Model):
title = ndb.StringProperty()
description = ndb.TextProperty()
class FavoriteMovie(ndb.Model):
user = ndb.KeyProperty(kind=User)
movie = ndb.KeyProperty(kind=Movie)
rating = ndb.IntegerProperty()
2 番目のアプローチを取る利点の 1 つは、ユーザーがお気に入りの映画に付けた評価など、関係に関する追加情報を追加できることです。2 番目のアプローチを検討するもう 1 つの理由は、双方に多くの関係がある場合です。この例では、ユーザーは多くのお気に入りの映画を持っており、映画は多くのユーザーに好まれています。
人々がたくさんの好きな映画を持っているのか、それとも映画がたくさんの人々に愛されているのか分からないので、急いでデザインを変更する必要がないように柔軟に対応したいと考えています. さらに、ある時点でユーザーがお気に入りの映画を評価できるようにしたいかもしれませんが、ここでもある程度の柔軟性が必要です。しかし、私たちが知っていることの 1 つは、このサイトが大きくなった場合、効率が重要であり、最終的に柔軟性が効率の低下を意味する場合、効率を失うことは避けたいということです。2 番目のアプローチは懸念の原因です。なぜなら、関係をトラバースするにはデータベースへの追加の呼び出しが必要になるとドキュメントが警告しているためです。
したがって、効率が問題になるかどうかを知るには、実行する必要があるクエリの種類を確認する必要があります。この場合、最も一般的に実行されるクエリは、「Forest Gump をお気に入りとして持っているすべてのユーザーを教えてください」のようなものになります。映画」または「フォレスト・ガンプとキャスト・アウェイをお気に入りの映画として持っているすべてのユーザーを教えてください」. また、いつどのデータが必要になるかを知る必要もあります。ほとんどの場合、これらのクエリに対してユーザー全体が戻ってくる必要はなく、代わりに必要なのは名前と、UI でユーザーのリストを作成するための写真だけです。これにより、データを少し非正規化し、ユーザーの名前と写真の URL を関係に入れることができます。
質問：
これらは、上記の問題に似た問題についての考えでした。お気づきかもしれませんが、私は多対多の関係をモデル化するために 2 番目のアプローチを使用することに傾いています。しかし、私が持っている1つの大きな懸念があります。2 番目のクエリ例では、Forest GumpとCast Away をお気に入りとして持つユーザーを求めました。これが 2 番目のアプローチでどのように効率的に行われるかはわかりませんが、ユーザーがそのような質問をできることが重要です。また、Forest GumpまたはCast Away をお気に入りとして使用しているユーザーを求めると、どのような効果がありますか。これらの懸念は最初のアプローチを使用するのに十分ですか、それともここで検討していないさらに優れたアプローチはありますか?
この件に関するご意見をお待ちしております。
ありがとう、トム