使用 Python NDB 有效实现一对多关系答案

【问题标题】：Effective implementation of one-to-many relationship with Python NDB使用 Python NDB 有效实现一对多关系
【发布时间】：2013-01-22 05:45:32
【问题描述】：

我想听听您对使用 Python NDB 有效实现一对多关系的意见。（例如 Person(one)-to-Tasks(many)）

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

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

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

非常感谢您的意见。

【问题讨论】：

【解决方案1】：

你缺少的一个关键点：你是如何读取数据的？

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

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

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

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

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

【讨论】：

嗨@dragonx，谢谢你的回答！是的，“如何读取数据”非常重要。如果我需要重复的结构化属性值的一部分（例如，由“重要”标记的任务），由于反序列化的 CPU 时间，我可能需要单个实体。另外，我没有考虑 1MB 的限制。谢谢你指出。我想澄清一点。查询“with”重复的结构化属性NOT很糟糕，不是吗？为了查询实体，App Engine 使用索引。因此，查询成本与使用其他属性进行查询相同。我错了吗？
查询成本不是问题。查询重复的结构化属性有一些奇怪的行为。您必须专心并解决它们。仔细阅读有关 ndb 属性和查询的文档。 developers.google.com/appengine/docs/python/ndb/…developers.google.com/appengine/docs/python/ndb/…
感谢您的回答，@dragonx！肯定是的。查询重复的结构化属性有点棘手。当需要查询时，我需要小心。
抱歉，还有一件事我忘了说。超出每个实体 1MB 的限制，每个实体的索引属性数量有一个限制，我认为是 5000。如果您使用重复的结构化属性，那是另一回事，我相信您可以比您更快地咀嚼这 5000 个索引属性会期待的。也要小心。
感谢您提供的信息，@dragonx。我完全忘记了搜索索引的限制。我不认为它消耗得很快。我会仔细检查文档。你的建议真的很有帮助。

【解决方案2】：

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

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

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

【讨论】：