国際的な大手ブランドの g+ アプリケーションを設計しています。作成する必要があるエンティティはほぼグラフの形式であるため、双方向にトラバースできるノードを接続する多対多の関係 (アーク) が多数あります。私はすべての読み取り可能なドキュメントをオンラインで読んでいますが、ndb 設計のベスト プラクティスとガイドラインに固有のものはこれまでのところ見つかりませんでした。残念ながら、私は NDA の下にあり、アプリの詳細を明らかにすることはできませんが、議事録、著者、論文、およびトピックを含む科学会議のコンテキストにほぼ 1 対 1 で一致させることができます。
これまでに想定されたエンティティのリストの下 (言及されたトピックに一致するようにコンテキストがシフトされています):
- 組織 (例: acm)
- 会議 (例: acm マルチメディア)
- 会議の問題 (例: acm マルチメディア 13)
- カンファレンス トラック (例: nosql、機械学習、コンピューター ビジョンなど)
- 作者（例：自分）
- 論文 (例: 「ndb の db のようなグラフの設計」)
ご覧のとおり、グラフを任意の方向 (またはフロントエンドの観点からはファセット) にアクセスしてトラバースできます。
- 著者と共著者
- オーサーから会議トラックへ
- 論文への会議トラック
- ...
など、リストを埋めます。
多くの宣伝とともに立ち上げられ、コンテンツとユーザー数の両方で、時間の経過とともに一貫してスケーリングする必要があるため、私はそれをまっすぐでしっかりしたものにしたいと考えています. 私はそれをゼロからコーディングしたいので、独自のモデル、このデータを読み書きするための安らかなAPIを設計し、非rel djangoを避け、プレゼンテーションレイヤーを最小限のテンプレートメカニズムに保ちます。私が働いている会社に確認する必要がありますが、適切なオープン ソース ライセンス (理想的には、ndb モデルの安らかなサービス) でコードの一部をリリースできる可能性があります。
誰かが私を正しい方向に向けることができれば、それは素晴らしいことです.
ありがとう！トーマス
[編集: 多対多の関係に関連するタイプミスを修正]