有效实现与Python NDB的一对多关系

Question

我想听听您对有效实现与Python NDB的一对多关系的看法.(例如人(一)到任务(很多))

根据我的理解,有三种方法可以实现它.

1. 使用'parent'参数
2. 使用'重复'结构化属性
3. 使用'重复'键属性

我通常会选择一种基于下面逻辑的方法,但这对你有意义吗？如果你有更好的逻辑,请教我.

1. 使用'parent'参数

   • 这些实体之间需要进行交易操作
   • 这些实体之间需要双向引用
   • 强烈打算"亲子关系"

2. 使用'重复'结构化属性

   • 不需要单独使用'many'实体(始终与'one'实体一起使用)
   • 'many'实体仅由'one'实体引用
   • '重复'的数量小于100

3. 使用'重复'键属性

   • 需要单独使用'many'实体
   • "许多"实体可以由其他实体引用
   • '重复'的数量超过100

No.2增加了实体的大小,但我们可以保存数据存储区操作.(我们需要使用投影查询来减少反序列化的CPU时间).因此,我尽可能地使用这种方式.

我非常感谢你的意见.

Answer 1

您缺少的一个关键事项:您如何阅读数据？

如果您在请求中显示给定人员的所有任务,则2有意义:您可以查询此人并显示他的所有任务.

但是,如果您需要查询说明在特定时间到期的所有任务的列表,则查询重复的结构化属性是非常糟糕的.您需要个人实体来完成任务.

还有第四个选项,即在任务中使用指向您的Person的KeyProperty.当您需要一个人的任务列表时,您可以发出查询.

如果您需要搜索单个任务,那么您可能想要使用#4.您也可以将它与#3结合使用.

此外,重复属性的数量与100无关.它与Person和Task实体的大小有关,以及多少适合1MB.这是有潜在危险的,因为如果您的Task实体可能很大,那么您的Person实体中的空间可能会比预期的更快.

Answer 2

大多数GAE用户将会意识到的一件事(迟早)是数据存储区不鼓励根据在关系数据库中被认为是好主意的正式规范化原则进行设计.相反,它似乎经常鼓励设计对既定规范不直观和诅咒.虽然关系数据库设计原则有它们的位置,但它们在这里不起作用.

我认为数据存储区设计的基础有两个问题:

1. 我如何阅读这些数据？如何以最少的读取操作读取它？

2. 以这种方式存储会导致写入和索引操作数量的爆炸吗？

如果你用尽可能多的远见和实际测试回答这两个问题,我认为你做得很好.您可以将其他规则和具体案例正式化,但这些问题大部分时间都可以使用.