在RavenDB中更改"架构"

cod*_*dog 19 .net nosql ravendb

只是为了扩展我的知识,我开始研究各种NoSQL选项.我访问的第一个是RavenDB,它看起来很有趣.我仍然试图打破我的深层关系思维,以及典型的RDBMS维护程序.

在我与Entity Framework的日常交易中,我们通过编写DB更改脚本的例程,刷新EF映射模型等.它在NoSQL中是如何工作的,尤其是RavenDB?一旦应用程序生效,如何更改各种POCO对象等并将其部署到生产中?存储在旧POCO类中的数据会发生什么变化?

我还没有深入研究或使用过Raven DB.一旦我这样做,这可能是显而易见的,但我很想知道,所以我不会将自己编入角落.

感谢:D.

Rob*_*ton 27

它们保持不变 - 加载时会忽略不再存在的属性(并且在更改时丢失),并且缺少的属性将返回null,

建议您使用基于集合的操作来使用对象模型来检查数据.

哦,看着我,我现在在电脑上!

正确地说,在转移到文档存储区时,您正确认识到丢失了某些功能并获得了一些自由,因为在数据库中您定义了前期架构并尝试上载与该架构不匹配的数据导致错误.

然而,重要的是要认识到,无模式和无结构之间存在差异,因为您的文档都包含自己的结构(键/值对表示属性名称和属性值).

这使得它对于编写一些代码和保持数据的整个"刚刚开始"因素非常有用 - 但是当你很容易改变你的代码结构时,很难将它与你已经持久化的数据进行协调.

在这一点上,有一些策略出现:

  • 一旦持久化数据,对类进行版本化,就可以使结构不可变
  • 允许修改结构,但使用基于集合的操作来更新数据以匹配新结构
  • 允许修改结构,并编写代码以在加载数据时处理不一致

第三个显然是一个坏主意,因为它会导致无法维护的代码,如果你只是存储事件或其他类似的数据,那么你的类的版本可以工作但是对于大多数场景来说并不是真的适合你,所以你只剩下中间选项.

我建议这样做,并遵循一些简单的规则,就像你在处理关系数据库中的前端模式时所遵循的那样.

  • 使用VCS系统确定已部署版本之间的更改
  • 编写从一个版本升级到另一个版本的迁移脚本
  • 小心重命名/删除属性 - 如果新文档中不存在这些属性,则加载文档并保存文档将导致数据丢失

等等.

我希望这更有帮助:-)