面向文档的数据库 - 如果文档定义发生变化怎么办？

Question

据我了解，您可以将任何非结构化信息输入到面向文档的数据库中。让我们想象一下这样的文档：

{
  name: 'John Blank',
  yearOfBirth: 1960
}

稍后，在新版本中，此结构将重构为

{
  firstname: 'John',
  lastname: 'Blank',
  yearOfBirth: 1960
}

如何使用面向文档的数据库执行此操作？您是否必须准备合并脚本，这会改变数据库中的所有条目？或者有更好的方法可以处理结构的变化吗？

Answer 1

这里的重构意味着从旧模式到新模式的确定性映射。因此，最有效的选择是执行与SQL数据库相同的操作并实际更新文档。

面向文档的数据库确实为您提供了另一种选择，但它取决于哪个DODB以及您在前端如何使用它。该选项只是简单地保留数据，并支持应用程序中的“旧”定义作为一种向后兼容性选项。换句话说，您正在进行这些翻译，而不是永久性的一次性更新。

这不是SQL数据库的一个选项，因为您必须保留过时的列并可能编入索引。使用DODB，您实际上不会浪费任何数据或索引空间。你必须权衡优势与劣势。

显然，主要的缺点是不一致，这可能会随着时间的推移而增长并导致错误。另一个缺点可能是在运行中执行此操作的计算开销，或者无法有效使用新结构（例如，您可能只想在lastname上编制索引）。所以，大多数时候，我想我会选择进行批量更新。

然而，保留旧文件有一个明显的优势;如果您不确定您的重构是否完美 - 例如，如果您的name列中的数据没有遵循一致的约定，可能在某些情况下它是lastname, firstname而在其他情况下它是{ {1}}在其他情况下firstname lastname - 然后在不进行永久更新的情况下即时进行转换，可以随时修改映射，以便您可以使用company name和{ {1}}字段可用时返回firstname猜测游戏以获取旧数据。

如上所述，我可能会为特殊情况保留第二个选项，我不相信我能够为每个记录/文档获得正确的“重构”。尽管如此，您可以选择使用其他类型的数据库。

除了这两个，我没有看到任何其他明确的选择。这是一种二元决策;您是永久更新现有数据还是不是。