【发布时间】：2013-07-09 09:29:48
【问题描述】：
直截了当，是否仍然可以在 Google App Engine 数据存储区中保留一个规范化的二维模型，其中每个关系本身就是一种类型，其实体是关系的实例？
我已经知道 Datastore（及其底层 Bigtable 技术）与 RDBM 系统的工作方式不同，但我的问题是：是什么阻止了人们仍然以关系方式（包括所有从理论和规划的角度来看它的优势）在 Datastore 中？
举例说明。难道我还不能计划以下类型的实体：
- 人员（姓名：str，公司：公司）
- 公司（名称：str）
- 项目（备注：文本）
- PersonProjects (Person:Person, Project:Project)
引用其他实体（例如 Person.Company、PersonProjects.Project）的属性将存储这些实体的 ID。 性能方面的主要缺点（如果有的话）是什么？ 请注意，我可以进一步规范化模型，例如为 PersonName、CompanyName 等引入了新类型，但我决定在这里将单值属性保留在它们所指的同一类型中。
我记得前段时间看过 I/O 系列的一个视频（由同一个 Google 制作），其中使用规范化技术来防止某种实体太大，即具有太多属性（问题实际上涉及爆炸索引）。计划类型的一个属性作为一种新类型从它“分离”出来，然后通过代码对其进行扩充。
好吧，我不能对所有类型的属性都这样做吗？除了客户端（或服务器端）工作的增加（需要“设置”对象以进行检索）之外，我看不到任何重大问题。 那么，切换到“基于实体”的模型真的有必要吗？我们不能通过种类和实体来模拟关系吗？
我希望我已经足够清楚了。
【问题讨论】：
-
可以，但出于性能原因，您通常需要制作组合。当您需要多对多关系时，我使用中间实体。
-
感谢您的回复。但是你暗示的性能问题到底是什么？这基本上就是我需要知道的。
-
当事情开始需要很长时间时，您就会知道。请记住，您不能进行连接。因此，您想通过依赖于关系另一端的值的查询检索的任何内容都变得昂贵，如果您需要 2 级以外的值，那么它将花费很大。分析您的应用程序，您将更好地了解需要优化的内容。目前你的问题太开放了，正确的答案取决于你在做什么。
-
我确实关心应用程序的最终查询功能。在此处假设的准规范化模型中，我将通过对规范化字段（如您所说）进行的多个微查询来检索（或完成）我的人工构造的对象。示例：对于 Person 对象，我将使用 .Person = 对象的 id 查询 PersonProjects.Project 的 Projects。我确信 Datastore 提供了一些基于键的查询工具，而且我认为这不会很昂贵，因为只涉及基本索引。那么，性能瓶颈在哪里呢？查询不是引擎的强项吗？
-
按键获取速度很快，当您从主查询中迭代超过 100 个或更多实体时会出现问题，这需要获取额外的项目。
标签： google-app-engine google-cloud-datastore relational