在低级数据存储 api 中处理一对多关系的最佳方法是什么？答案

【问题标题】：What is the best way to handle one to many relationships in the low level datastore api?在低级数据存储 api 中处理一对多关系的最佳方法是什么？
【发布时间】：2010-06-30 00:10:14
【问题描述】：

我已经在 Java 中使用 App Engine 的低级数据存储 API 有一段时间了，我正在尝试找出处理一对多关系的最佳方法。想象一下一对多的关系，例如“任何一名学生可以拥有零台或多台计算机，但每台计算机只属于一名学生”。

两个选项是：

让学生实体存储与学生关联的计算机的密钥列表
让计算机实体存储拥有计算机的学生的单个密钥

我觉得选项二更好，但我很好奇其他人的想法。

选项一的优点是您可以在不使用查询的情况下取回所有“许多”。可以使用 get() 并传入存储的键列表来向数据存储询问所有实体。这种方法的问题是您不能让数据存储对从 get() 返回的值进行任何排序。您必须自己进行分类。另外，您必须管理一个列表而不是单个 Key。

选项二看起来不错，因为没有要维护的列表。此外，您可以按计算机的属性进行排序，只要它们是该属性的索引即可。想象一下，尝试为学生获取所有计算机，结果按购买日期排序。方法二是一个简单的查询，在我们的代码中没有进行排序（数据存储的索引负责它）

排序并不难，但比有一个排序索引（~O(n) 遍历索引）要花费更多时间（~O(nlogn) 进行排序）。权衡是处理时间的索引（数据存储中的空间）。正如我所说，我的直觉告诉我，选项二是一个更好的通用解决方案，因为它为开发人员提供了更多的灵活性，可以以额外的索引为代价（使用谷歌定价模型非常便宜）来按顺序获取结果。有没有人同意、不同意或有 cmets？

【问题讨论】：

您可能还有第三种选择，即为用户存储记录中的所有计算机。不过，我不熟悉您提到的数据存储。
在用户记录中存储计算机可能对 GAE 的数据存储不太适用。这样做会有点棘手（它可能需要计算机模型中的每个字段一个ListProperty - 而且这些都不能被索引，否则你会有一个爆炸性的索引问题）。如果您不需要搜索计算机，并且您不介意在检索学生实体时始终检索所有学生计算机信息的开销，这可能没问题。

标签： java google-app-engine google-cloud-datastore

【解决方案1】：

这两种方法在不同情况下都有效，但选项二 - 在“多”端存储单个引用 - 是更常见的方法。您使用哪一种取决于您需要如何访问您的数据。

【讨论】：

【解决方案2】：

您是否考虑过两者都做？然后，您可以通过键快速获取学生拥有的计算机列表，或者使用以某种排序顺序返回结果的查询。我认为在学生模型上维护一个键列表并不像您想象的那样令人生畏。

不要低估直接通过键获取实体的好处。根据this article 的说法，这可以比查询快 4-5 倍。

【讨论】：

“不要低估直接通过键获取实体的好处。根据这篇文章，这可以比查询快 4-5 倍。”文章在提及该号码时引用了系统状态页面 (code.google.com/status/appengine)。但是这样的比较是不是有点不公平。我想 get 通常用于返回单个条目，而查询通常会返回更多数据 - 有时更多。