我正在为一个国际大品牌设计一个 G+ 应用程序。我需要创建的实体几乎都是图形形式，因此有很多多对多关系(弧)连接可以双向遍历的节点。我正在在线阅读所有可读文档，但到目前为止我还没有找到任何特定于 ndb 设计最佳实践和指南的内容。不幸的是，我处于保密协议(protocol)之下，无法透露该应用程序的详细信息，但它可以几乎一对一地匹配科学 session 的背景，包括 session 记录、作者、论文和主题。
在迄今为止设想的实体列表下方(上下文已转移以匹配提到的主题):
- 组织(例如 acm)
- session (例如 acm 多媒体)
- session 问题(例如 acm多媒体13)
- session 主题(例如 nosql、机器学习、计算机视觉等)
- 作者(例如我自己)
- 论文(例如“为 ndb 设计类似 db 的图形”)
如您所见，我可以通过任何方向(或从前端的角度来看)访问和遍历该图:
- 作者与共同作者
- session 轨道的作者
- session 记录到论文
- ...
依此类推，您填写列表。
我想让它变得直接和坚实，因为它将在发布时获得很多公关。并且需要在内容和用户数量上持续不断地扩展。我想从头开始编码，因此设计我自己的模型，restful api 来读取/写入这些数据，避免非 rel django 并将表示层保持在最小模板机制。我需要与我工作的公司核实，但我们也许能够使用适当的开源许可证发布部分代码(理想情况下，为 ndb 模型提供 Restful 服务)。
如果有人能指出我正确的方向，那就太好了。
谢谢! 托马斯
[编辑:更正了与多对多关系相关的拼写错误]
最佳答案
有两种方法可以在 App Engine 中实现一对多关系。
在实体 A 内，存储实体 B1、B2、B3 的键列表。在旧数据库中，您将使用 db.Key 的 ListProperty。在 ndb 中，您可以使用重复 = True 的 KeyProperty。
在实体 B1、B2、B3 内部，将 KeyProperty 存储到实体 A。
如果您使用 1:
- 当你有实体A时，你可以通过id获取B1，B2，B3。这可能比查询结果更一致。
- 它可能会稍微便宜一些，因为您在查询中节省了 1 次读取操作(假设您不计算获取实体 A 的成本)。编写 B 实例稍微便宜一些，因为它减少了一个需要更新的索引。
- 您可以存储的 B 实例数量受到最大实体大小和 A 上索引属性数量的限制。这对于 session 轨道等内容很有意义，因为通常有有限数量的轨道无法存储数以千计。
- 如果您需要对 B1、B2、B3 进行任意排序，将它们按顺序存储在列表中比使用某些排序索引属性对它们进行排序更容易。
如果您使用 2:
- 您只需要实体 A 的 Key 即可查询 B1、B2、B3。您实际上不需要获取实体 A 来获取列表。
- 您可以拥有几乎无限数量的 B 实体。
关于python - appengine ndb 上类图实体的最佳实践，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18017150/