1

我正在为一个国际大品牌设计一个 g+ 应用程序。我需要创建的实体几乎都是图的形式，因此有很多多对多关系（弧）连接可以双向遍历的节点。我正在在线阅读所有可读的文档，但到目前为止我还没有找到任何特定于 ndb 设计最佳实践和指南的内容。不幸的是，我处于保密协议下，无法透露该应用程序的详细信息，但它几乎可以一对一地匹配科学会议的背景与会议记录、作者、论文和主题。

在目前设想的实体列表下方（上下文转移以匹配所提到的主题）：

  • 组织（例如 acm）
  • 会议（例如 acm 多媒体）
  • 会议问题（例如 acm 多媒体 13）
  • 会议轨道（如nosql、机器学习、计算机视觉等）
  • 作者（例如我自己）
  • 论文（例如“为 ndb 设计类似 db 的图形”）

如您所见，我可以通过任何方向（或方面，从前端的角度）访问和遍历图形：

  • 作者与合著者
  • 会议轨道的作者
  • 会议轨道到论文
  • ...

依此类推，您填写列表。

我想让它直截了当，因为它会启动很多公关，并且需要在内容和用户数量方面持续不断地扩展。我想从头开始编写代码，因此设计我自己的模型，restful api 来读取/写入这些数据，避免非 rel django 并将表示层保持在最小的模板机制。我需要与我工作的公司核实，但我们也许可以使用体面的开源许可证发布部分代码（理想情况下，为 ndb 模型提供宁静的服务）。

如果有人能指出我正确的方向，那就太棒了。

谢谢！托马斯

[编辑：更正与多对多关系相关的错字]

4

2 回答 2

1

在 App Engine 中实现一对多关系有两种方法。

  1. 在实体 A 中，存储实体 B1、B2、B3 的键列表。在旧数据库中，您将使用 db.Key 的 ListProperty。在 ndb 中，您将使用带有重复 = True 的 KeyProperty。

  2. 在实体 B1、B2、B3 内部，将 KeyProperty 存储到实体 A。

如果您使用 1：

  • 当您拥有实体 A 时，您可以通过 id 获取 B1、B2、B3。这可能比查询结果更一致。
  • 它可能会稍微便宜一些，因为您在查询中保存了 1 个读取操作（假设您不计算获取实体 A 的成本）。编写 B 实例会稍微便宜一些，因为要更新的索引少了一个。
  • 您可以存储的 B 实例数量受到 A 上最大实体大小和索引属性数量的限制。这对于会议轨道之类的事情是有意义的，因为通常只有有限数量的轨道不会进入数千个.
  • 如果您需要对 B1、B2、B3 的顺序进行任意排序，将它们按顺序存储在列表中比使用某些已排序的索引属性对它们进行排序更容易。

如果您使用 2：

  • 您只需要实体 A 的 Key 即可查询 B1、B2、B3。您实际上不需要获取实体 A 来获取列表。
  • 您可以拥有几乎无限数量的 B 个实体。
于 2013-08-03T16:45:42.817 回答
0

经过深入研究，发现：

  • 没有单一的设计模式可以遵循，这当然取决于具体的应用程序和数据建模（很公平）
  • 应采取措施避免达到本页底部列出的大小限制，主要针对单个实体大小 (1mb)、事务大小 (10mb) 和索引限制
  • 尽可能避免实体规范化（例如，让实体仅用于创建一组弧线），尽管 googleplus 开发人员在他们的演示应用程序中似乎将其用于简单的社交图

欢迎任何其他更详细的答案

于 2013-08-08T16:15:04.640 回答