私のプロジェクトのDjangoモデル構造

Question

私はテキストベースのブラウザゲームを作成しており、djangoモデル構造についてのアドバイスが必要です。すべての例は同じプロジェクトのものですから、上から下にすべての質問を読んだと仮定して同じ情報を繰り返すことはありません。

---

最初の質問

私はすべてのプレイヤーが参加する労働組合との両方の選手とのための報酬を表しmedalsアプリに関する情報を保持しているユーザ・プロファイル（Playerモデル）が含まれていauthアプリ、allianceアプリを持っています同盟。

メダルを割り当てることができるので、PlayerとAllianceのモデルのM2MフィールドをMedalにリンクすることができます。

別のオプションでは、medalsアプリを他のどのプロジェクトでも使用できます。このアプローチには、PlayerまたはAllianceのいずれかにリンクするMedalモデルの汎用関係の使用が含まれます。

どちらのソリューションがもっとジャンゴ様ですか、したいですか？

---

2番目の質問

達成するプレーヤーのためのタスクがあります。タスクのシナリオは大きく異なります。したがって、タスクごとに固有のタスク進捗チェックコードを書くには、何らかのアプローチが必要です。

タスクは、報酬に関する情報を含むデータベースに保持されます（これはほとんど同じです）。各タスクに固有のコードはどこに書くべきですか？たぶん私はいくつかのフィールドを追加し、後でそれらを評価する必要がありますか？すべての情報はDBに保存されます。

さらに、タスクではいくつかのトラッキングが必要です。たとえば、手動セクションに行くという簡単な作業を想像してください（プレイヤーがどこにいるかを知るためです）。次に、プレイヤーがマニュアルページを訪問したかどうかをどこかに登録する必要があります。私は別のモデルTaskTrackersタスクのアプリケーションで作成すると思います。その後、別の質問が発生します。 OneToOneフィールドをPlayerからTaskTrackersに、またはその逆に追加する必要がある場合は、

---

まとめると、主な問題は、私は、ユーザー・プロファイル・モデルにOneToOneFields/M2Mフィールドを追加したり、Userモデルに対象モデルからOneToOneFields/Foreigneysを追加するかどうかですか？後者は私のアプリをより再利用可能にしますが、最初のアプローチはもっと論理的かもしれません。

回答を待っています。

Answer 1

あなたの最初の質問の1つは、M2Mからメダルにするか、一般的な外部キーを使用することです。あなたはM2Mといくつかの結合テーブルで終わるでしょう。一般的な外部キーでは、結合テーブルはありませんが、コンテンツタイプの追加クエリがあります。したがって、両方の方法を設定して、パフォーマンスにどのような影響を及ぼすかを確認する必要があります。

2番目の質問では、1つまたは複数の「ステップ」モデルを使用して「タスク」モデルを使用する方法があります。インラインformsetとして設定することができます。次に、「CompletedPlayerTasks」などのようなテーブルが必要です。そのようなテーブルには、プレーヤID、タスクID、およびステップIDが含まれています。そのテーブルにステップIDが存在する場合、タスクは完了しています。

Djangoでは難しいことではない、各タスクのステップのカスタムフィールドとフォームを作成する必要があるようです。これを行うにはsome off the shelf solutionsがありますが、自分で作成する必要があるかもしれません。

最後に、Djangoのcontrib.authアプリに名前空間の問題を引き起こす可能性のあるユーザープロフィール「auth」を保持するアプリケーションの名前を付けません。私はそれを「プロファイル」と名付けます。ちょうどそのアプリケーションが何をしているのかがはっきりしています。

希望はあなたにいくつかのアイデアを提供します。