5

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

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

后来，在新版本中，这个结构被重构为

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

您如何使用面向文档的数据库来做到这一点？您是否必须准备合并脚本来更改数据库中的所有条目？还是有更好的方法可以处理结构的变化？

4

1 回答 1

3

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

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

对于 SQL 数据库，这并不是一个真正的选项，因为您必须保留过时的列并可能对其进行索引。使用 DODB，您并没有真正浪费任何数据或索引空间。你必须权衡利弊。

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

然而，保留旧文件有一个明显的优势；如果你不确定你的重构是否完美——例如，如果你的name列中的数据没有遵循一致的约定，也许在某些情况下是这样lastname, firstname，在其他情况下是这样firstname lastname，在其他情况下是这样company name——然后做你的转换-the-fly 无需进行永久更新，允许您随着时间的推移改进映射，因此您可以在可用时使用firstname和lastname字段，但回退到name遗留数据的猜谜游戏。

如前所述，我可能会为特殊情况保留第二个选项，在这种情况下，我不确定我能否为每个记录/文档正确进行“重构”。然而，它是一个可供您使用的选项，而您在其他类型的数据库中并不真正拥有。

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

于 2010-05-16T23:41:04.887 回答