文档数据库:数据模型迁移

时间:2012-11-30 10:02:13

标签: mongodb ravendb nosql

像我们大多数人一样,我来自关系数据库世界, 我目前正在研究文档数据库世界的可能性。 我关注的一个问题是随着时间的推移处理数据模型的变化(添加新属性,重命名属性,添加关系,......)。

在关系数据库中,通常按如下方式处理:

  • 编写数据库迁移
         - >修改数据库模式
         - >修复现有行的数据(通常包含一些业务逻辑)
  • 修改代码(ORM更新,..)


使用文档数据库时,我感觉数据模型发生了变化 更容易;没有必要更新数据库模式,主要是它只是添加一个属性,......而且“一切正常”。 我想知道团队如何在现实生活中管理这种迁移,包括文档数据库的企业项目:

  • 是否有严格的政策来更改存储在文档数据库中的类型? 例如,对此类型的每次更改都需要迁移才能更新 现有文件?
  • 因此,数据模型(存储在文档数据库中的类型)与业务模型之间是否存在明确的分离?

感谢您的时间,
科恩

2 个答案:

答案 0 :(得分:1)

答案 1 :(得分:1)

您可以在MongoDB中对“架构”修改采取三种通用策略。我看到这三个人都很好;您将使用哪一个取决于您的特定用例。

首先:您可以简单地向新文档添加新字段,并编写代码以处理该字段不存在的情况。例如,您可以在“用户”文档中添加“address”字段,但是您必须编写客户端代码来处理该字段不存在的情况。

第二:您可以编写代码来查看现有文档&当它看到“旧式”文档时更新它。例如,您可以使用代码检查“用户”文档中是否存在“name”字段。如果找到该字段,则会将其拆分为“first_name”和“sur_name”字段,$unset该文档中的“name”字段,以及{{ 1}}新的“$set”和“first_name”字段为其计算值。

第三:您可以批量更新集合中的所有文档以使用新架构。您可以编写与上面相同的代码,但是当您的应用程序读取文档时,不是懒惰地应用它,而是将其应用于集合中的所有文档。

请注意,最后一个策略可能会对性能产生影响:如果您在很多文档中分页了一段时间没有访问过,那么您将在MongoDB系统上额外加载。

相关问题