是否可以在Google App Engine中保留标准化模型？

直接指向这一点，是否可以在Google App Engine数据存储区中保留一个标准化的二维模型，其中每个关系本身就是一种类型，其实体是关系的实例？是否可以在Google App Engine中保留标准化模型？

我已经知道数据存储（其底层的Bigtable技术）的工作原理不同于RDBM系统，但我的问题是：是什么阻止一个从仍然在关系的方式奠定了他们的模型（与从所有的优点理论和规划的角度）在数据存储区内？

一个例子来澄清。我不能仍然计划以下类型的实体：

人（姓名：STR，公司：公司）
公司（名称：STR）
项目（注：文）
PersonProjects（人：人，项目简介：项目）

引用其他实体的属性（如Person.Company，PersonProjects.Project）将存储这些实体的标识。主要缺点（如果有的话）是什么，性能明智？请注意，我可以进一步标准化模型，例如，为PersonName，CompanyName等引入新类型，但我决定在这里保持它们引用的相同类型的一个值属性。我记得前段时间看过I/O系列（由Google制作）的视频，其中使用了规范化技术来防止某种类型的实体太大，即具有太多属性（问题实际上涉及爆炸索引）。计划种类中的一个属性作为一种新类型被“分离”，只是在通过代码后才被扩展。

那么，我还不能为所有的一种属性做到这一点吗？除了增加客户端（或服务器端）工作（需要获取“设置”用于检索的对象）之外，我看不到任何主要问题。那么，切换到“基于实体”的模型是否真的有必要？我们难道不能通过种类和实体来模拟关系吗？

我希望我已经清楚了。

来源

2013-07-09 atava

您可以，但您通常需要为了性能原因进行组合。当你需要多对多关系时，我使用中间实体。 –

感谢您的回复。但是，你暗示的性能问题究竟是什么？这基本上是我需要知道的。 – atava

当事情开始需要很长时间时，你会知道它。记住你不能做连接。因此，任何想要通过依赖于关系另一端的值的查询来检索的任何东西都会变得非常昂贵，如果您需要一个2级别的值，那么它将花费很大。剖析您的应用程序，您将更清楚您需要优化的内容。在你的问题太过开放的时刻，正确的答案取决于你在做什么。 –

没有什么能阻止你在数据存储中规范你的模型。问题是Datastore的查询语言非常有限：仅在一个属性上进行不等式过滤，没有多类查询，没有JOIN等。这迫使您根据访问模式组织数据：面向访问的建模。这通常会迫使您将数据存储在不合逻辑的地方，以便快速获取数据（=最小的数据库操作集）。

此外，事务处理非常有限，迫使您以某种方式组织数据（实体组）。或者如果您使用XG交易，那么您每次交易将被限制为25个实体。

另请注意，SQL RDBM中通常没有DB强制的参照完整性。

来源

2013-07-09 12:42:15

迄今为止我收到的反馈使我确信，虽然可能，但整个关系类模型不适用对于数据存储区，就像现在一样。是的，所有这些都是由于缺少内置的查询功能，如JOIN等（同样由于对象在Bigtable中存储和检索的方式），需要依赖多个查询来“构建”单个标准化对象领域。（参考完整性并不是什么大问题，因为我已经应对了代码方面的问题，并且引擎已经呈现为“松散”了。）感谢您的回复！ – atava

是否可以在Google App Engine中保留标准化模型？

回答

相关问题