2

如果您使用无模式数据库（特别是面向文档的数据库，如 CouchDB、Couchbase、MongoDB）并且想要更改特定对象的数据表示格式，您可能会使用旧格式保留现有记录并以新格式创建新记录。它被宣布为无模式数据库的主要优势之一（我认为是因为您可以避免停机）。另一方面，处理多种格式的同种数据既不方便又低效。那么在无模式数据库中将数据从一种格式迁移到另一种格式的好方法/策略是什么？

4

1 回答 1

8

像所有事情一样，有很多不同的方法来处理这个问题。在无模式开发中，您通常知道您正在存储的数据。并不是缺少架构，所有数据都有隐式架构，所以我们真正要说的是数据库没有强制执行架构。如果我有一个存储在 json 中的具有 10 个实例变量的用户对象，那么那里就有一个模式！

案例 1：值可能有不同的可能性，单个值、数组或嵌套结构

情况 2：值需要从一种格式更改为另一种格式，例如。从单个值到值数组

案例 3：json 键的存在或不存在，这很简单

对于案例 1：如果您期望 json 值的多样性，则需要将特定值的多样性写入您的应用程序代码逻辑，如果是字符串，请执行此操作，如果是数组，请执行此操作。

对于案例 2：一种方法可以将其作为“按需”或“按需”处理，以便您将转换逻辑烘焙到您的类方法中，以便将数据从一种格式转换为另一种格式。这意味着您在检索数据时将数据从一种格式转换为另一种格式。您还可以标记它以表明您已对其进行了转换。由于它是按需的，因此您的文档存储中可能有未“转换”的数据，但如果它确实被请求，它将被转换。

案例 2 的替代方法：通过工作进程迭代和转换数据。因此，与其等待它被请求，您实际上创建了一个作业来更改您希望更改的数据，将转换逻辑烘焙到工作人员本身（可以在您的应用程序代码中使用相同的类定义）。在 Couchbase 中，您可以创建视图（二级索引）或使用弹性搜索来遍历特定类型的文档。如果您创建一个工作流系统，您可以与许多工作人员并行执行很多此操作。

>>>>当我进行转换时，我通常以非破坏性的方式 将一个 json k/v 转换为另一个 json k/v，这样如果我在处理过程中出错，我不会更改原始数据。如果我觉得有必要的话，我可以在稍后阶段删除旧的 json k/v“按需”。对于此类操作，这是一种更安全的方法。

附加

案例 1 & 2：数据转换

原始 JSON 文档

user::101        
{ 
  "uid": 1234,
  "type": user,
  "my_comment": "the quick brown fox jumped over the lazy dog"
  "version": 1.00
}

现在假设我想以非破坏性方式更改它，我可以轻松地添加一个具有转换后数据的新 json 键：

user::101        
{ 
  "uid": 1234,
  "type": user,
  "my_new_comment": ["the quick brown fox jumped over the lazy dog", "comment2"]
  "my_comment": "the quick brown fox jumped over the lazy dog",
  "version": 1.01

}

注意它是非破坏性的，旧的 json 键仍然存在，或者我可以这样做，将旧数据保存为新键，并将预期的 json 键更改为新格式（数组）而不是字符串：

user::101        
{ 
  "uid": 1234,
  "type": user,
  "my_comment": ["the quick brown fox jumped over the lazy dog", "comment2"],
  "my_comment_v1.00": "the quick brown fox jumped over the lazy dog",
  "version": 1.01
}

显然，您可以使用多种不同的方案，具体取决于您的喜好。

于 2012-11-20T17:46:07.980 回答