我想听听您对有效实现与 Python NDB 的一对多关系的看法。（例如人（一个）到任务（许多））
在我的理解中，有三种方式来实现它。
我通常根据以下逻辑选择一种方式，但这对您有意义吗？如果你有更好的逻辑，请教我。
使用“父”参数
使用“重复”结构化属性
使用“重复”键属性
No.2 增加了实体的大小，但我们可以节省数据存储操作。（我们需要使用投影查询来减少反序列化的 CPU 时间）。因此，我尽可能多地使用这种方式。
我真的很感激你的意见。
您缺少的一个关键问题：您如何读取数据？
如果您在请求中显示给定人员的所有任务，则 2 有意义：您可以查询此人并显示他的所有任务。
但是，如果您需要查询说在某个时间到期的所有任务的列表，那么查询重复的结构化属性是很糟糕的。您将需要单独的实体来完成您的任务。
还有第四个选项，即在您的任务中使用指向您的个人的 KeyProperty。当您需要某人的任务列表时，您可以发出查询。
如果您需要搜索单个任务，那么您可能想要使用#4。您也可以将它与#3 结合使用。
此外，重复属性的数量与 100 无关。它与您的 Person 和 Task 实体的大小有关，以及 1MB 可以容纳多少。这有潜在的危险，因为如果您的 Task 实体可能很大，您的 Person 实体中的空间可能会比您预期的更快用完。
大多数 GAE 用户迟早会意识到的一件事是，数据存储不鼓励根据正式规范化原则进行设计，这在关系数据库中被认为是一个好主意。相反，它似乎经常鼓励不直观的设计和对既定规范的厌恶。尽管关系数据库设计原则有其位置，但它们在这里不起作用。
我认为数据存储设计的基础分为两个问题：
我将如何读取这些数据以及如何以最少的读取操作次数读取它？
以这种方式存储它会导致写入和索引操作的数量激增吗？
如果你用尽可能多的远见和实际测试来回答这两个问题，我认为你做得很好。您可以将其他规则和特定案例正式化，但这些问题在大多数情况下都会起作用。