1

直奔主题，是否仍然可以在 Google App Engine 数据存储中保留一个标准化的二维模型，其中每个关系本身就是一种，而它的实体是关系的实例？

我已经知道 Datastore（及其底层 Bigtable 技术）与 RDBM 系统的工作方式不同，但我的问题是：是什么阻止了人们仍然以关系方式布置他们的模型（从理论和规划的角度来看，它的所有优势) 在数据存储区中？

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

  • 人（姓名：str，公司：公司）
  • 公司（名称：str）
  • 项目（注：文字）
  • PersonProjects（人：人，项目：项目）

引用其他实体（例如 Person.Company、PersonProjects.Project）的属性将存储这些实体的 ID。性能方面的主要缺点（如果有的话）是什么？请注意，我可以进一步规范化模型，例如为 PersonName、CompanyName 等引入新类型，但我在这里决定将单值属性保持在它们所指的同一类型中。

我记得前段时间看过一个来自 I/O 系列的视频（由同一个 Google 制作），其中使用规范化技术来防止某种实体太大，即具有太多属性（问题实际上涉及爆炸索引）。计划类型的一个属性作为一种新类型从它“分离”出来，然后通过代码对其进行扩充。

好吧，我不能对所有类型的属性都这样做吗？除了客户端（或服务器端）工作的增加（需要“设置”对象以进行检索）之外，我看不到任何重大问题。那么，切换到“基于实体”的模型真的有必要吗？我们不能通过种类和实体来模拟关系吗？

我希望我已经足够清楚了。

4

1 回答 1

1

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

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

另请注意，在 SQL RDBM 中通常不存在 DB 强制引用完整性。

于 2013-07-09T12:42:15.047 回答