Couchdb 将mySql数据表迁移到Clodant文档

我们计划从MySql迁移到CloudAntNoSQL。我想知道做这件事的最佳方法是什么。 我们有5个不同的表——产品（ProductId主键）、问题（IssueId主键、ProductId外键）、标签（标记id主键、ProductId外键）和位置（LocationId主键位置作为外键，位置在产品表中）和策略（policyId主键、IssueId作为主键）

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

为每一行保留不同的文档，每个表具有唯一的文档类型（对于每个表，文档类型为“产品”、“问题”、“标签”、“位置”、“策略”）

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

---

哪种方法更好？

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

这种方法允许您在一个Cloudant API调用（

get/products/prod1

）中获取产品的几乎所有信息。这样的调用将为您提供所有主要产品数据以及SQL世界中的连接—在本例中是事物数组或对象数组

您可能仍然需要另一个

位置数据库

或

策略

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

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

如果您的二次收集量较大，例如如果位置/标签/问题的数量会使产品文档的大小过大，则可能会存在这种情况

{ 
   _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"
     }
   ]
}