python - 使用 Python NDB 有效实现一对多关系

Question

我想听听您对有效实现与 Python NDB 的一对多关系的看法。（例如人（一个）到任务（许多））

在我的理解中，有三种方式来实现它。

1. 使用“父”参数
2. 使用“重复”结构化属性
3. 使用“重复”键属性

我通常根据以下逻辑选择一种方式，但这对您有意义吗？如果你有更好的逻辑，请教我。

1. 使用“父”参数

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

2. 使用“重复”结构化属性

   • 不需要单独使用“许多”实体（始终与“一个”实体一起使用）
   • “许多”实体仅由“一个”实体引用
   • “重复”的次数少于 100

3. 使用“重复”键属性

   • 需要单独使用“许多”实体
   • “许多”实体可以被其他实体引用
   • “重复”次数超过 100

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

我真的很感激你的意见。

Answer 1

您缺少的一个关键问题：您如何读取数据？

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

但是，如果您需要查询说在某个时间到期的所有任务的列表，那么查询重复的结构化属性是很糟糕的。您将需要单独的实体来完成您的任务。

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

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

此外，重复属性的数量与 100 无关。它与您的 Person 和 Task 实体的大小有关，以及 1MB 可以容纳多少。这有潜在的危险，因为如果您的 Task 实体可能很大，您的 Person 实体中的空间可能会比您预期的更快用完。

Answer 2

大多数 GAE 用户迟早会意识到的一件事是，数据存储不鼓励根据正式规范化原则进行设计，这在关系数据库中被认为是一个好主意。相反，它似乎经常鼓励不直观的设计和对既定规范的厌恶。尽管关系数据库设计原则有其位置，但它们在这里不起作用。

我认为数据存储设计的基础分为两个问题：

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

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

如果你用尽可能多的远见和实际测试来回答这两个问题，我认为你做得很好。您可以将其他规则和特定案例正式化，但这些问题在大多数情况下都会起作用。