直截了当地说，是否有可能在Google App Engine数据存储区中保留一个规范化的二维模型，其中每个关系本身就是一种类型，其实体是关系的实例？
我已经知道数据存储区（使用其基础Bigtable技术）与RDBM系统的工作方式不同，但我的问题是：什么阻止仍然以关系方式布局他们的模型（所有从理论和规划的角度来看，它在数据存储区内的优势？
澄清一个例子。我还不能计划以下类型的实体：
引用其他实体的属性（例如Person.Company，PersonProjects.Project）将存储这些实体的ID。 性能方面的主要缺点（如果有的话）会是什么？ 请注意，我可以进一步规范化模型，例如为PersonName，CompanyName等引入新类型，但我决定将one-value属性保持在它们引用的相同类型中。
我记得前段时间看过来自I / O系列（由同一家Google制作）的视频，其中使用了规范化技术来防止某种类型的实体过大，即具有太多属性（问题）实际上涉及爆炸指数）。计划类型的一个属性是作为一种新类型“脱离”它，后来通过代码扩展到它。
嗯，我还不能为所有类型的财产做到这一点吗？除了客户端（或服务器端）工作的增加（需要将对象“设置”用于检索）之外，我看不到任何重大问题。 那么，切换到“基于实体”的模型真的有必要吗？我们不能通过种类和实体来模拟关系吗？
我希望我已经足够清楚了。
答案 0 :(得分：1)
没有什么可以阻止您在数据存储区中规范化您的模型。问题是数据存储区的查询语言非常有限：仅对一个属性进行不等式过滤，没有多类查询，没有JOIN等。这会强制您根据访问模式组织数据：面向访问的建模。这通常会迫使您将数据存储在不合逻辑的位置，只是为了快速达到它（=最小的数据库操作集）。
此外，交易非常有限，迫使您以某种方式组织数据（实体组）。或者，如果您使用XG交易，那么每笔交易将限制为25个实体。
另请注意，SQL RDBM中通常没有DB强制的参照完整性。