将 mySql 数据表迁移到 Clodant 文档

Question

我们计划从 MySql 迁移到 Cloudant NoSql。我想了解这样做的最佳方法是什么。 我们有 5 个不同的表——产品（ProductId 主键）、问题（IssueId 主键、ProductId 外键）和标签（Tag id 主键、ProductId 外键）和位置（LocationId 主键位置作为外键与产品中的位置表）和Policy（policyId主键，IssueId为主键）。

现在我们想到了两种在 Cloudant 中维护文档的方法。

1. 为每一行保留不同的文档，每个表具有唯一的文档类型（对于每个表，一个文档类型前文档类型为 "product","issues,"tag","location","policy"）。

2. 为每一行保留不同的文档，并在一个文档中定义所有关系（所有类型为“产品”的文档仅在维护每个产品的所有标签、问题[策略]、位置的情况下）。

哪种方法更好？

Answer 1

答案实际上取决于数据的大小和增长率。在以前的 SQL->NoSQL 迁移中，我使用了您的第二种方法（我不知道您的确切架构，所以我猜）：

{ 
   _id: "prod1",
   name: "My product",
   tags: [
     "red", "sport", "new"
   ],
   locations: [
     {
       location_id: "55",
       name: "London",
       latitude: 51.3,
       longitude: 0.1
     }
   ],
   issues: [
     {
       issue_id: "466",
       policy_id: "88",
       name: "issue name"
     }
   ]
}

这种方法允许您在单个 Cloudant API 调用 (GET /products/prod1) 中获取有关产品的几乎所有信息。这样的调用将为您提供所有主要产品数据以及 SQL 世界中的联接 - 在本例中为事物数组或对象数组。

您可能仍需要另一个 locations 或 policies 数据库，因为您可能希望将有关这些对象的额外信息存储在单独的集合中，但您可以存储该数据的 子集 （例如位置的名称和地理位置）在产品文档中。这确实意味着从您的参考“位置”集合中复制每个产品中的一些数据，但会提高查询时的效率（以使数据更新更复杂为代价）。

这完全取决于您如何访问数据。为了速度和效率，您希望能够在尽可能少的 API 调用中检索呈现页面所需的数据。如果您将所有内容保存在自己的数据库中，那么您需要自己进行连接，因为 Cloudant 没有连接。这将是低效的，因为您需要为每个“加入”进行额外的 API 调用。

有another way to managed "joins" in Cloudant，如果你的二级收藏很大，这可能是合适的，例如如果位置/标签/问题的数量会使产品文档过大。