【发布时间】:2015-10-10 22:48:59
【问题描述】:
我看过很多关于 MongoDB 和 Mongoose 的视频和教程,虽然我认为 Mongoose 做得很好,但它与 NoSql 数据存储提供的灵活性不矛盾吗?那是一个无模式的环境。
如果我想在文档中添加新属性或数组怎么办?我必须正确更新我的 Mongoose 架构吗?这似乎与灵活文档存储的全部意义背道而驰。
如果我希望我的应用程序更灵活,Mongoose 不是我的应用程序的错误选择吗?
【问题讨论】:
我看过很多关于 MongoDB 和 Mongoose 的视频和教程,虽然我认为 Mongoose 做得很好,但它与 NoSql 数据存储提供的灵活性不矛盾吗?那是一个无模式的环境。
如果我想在文档中添加新属性或数组怎么办?我必须正确更新我的 Mongoose 架构吗?这似乎与灵活文档存储的全部意义背道而驰。
如果我希望我的应用程序更灵活,Mongoose 不是我的应用程序的错误选择吗?
【问题讨论】:
免责声明:我已经在一个非常大型的企业应用程序中使用 Mongoose 大约 2 年了,并且在那个 pre-mongoose 之上又使用了 mongo 一年。
文档提到
让我们面对现实吧,编写 MongoDB 验证、强制转换和业务逻辑样板是一种拖累。这就是我们编写 Mongoose 的原因。
除非你经历过痛苦,否则这句话很难理解。
梦想是这样的:您的应用程序是完美的,并且您将所需的内容存储在一个集合中。您可以轻松地抛出或获取数据。它非常适合 linux 管道,并且大部分都可以正常工作!
我认为现实情况是,我们经常低估我们的数据至少有轻微的相关性和影响。大多数应用程序会将 Mongo/NoSQL 视为非规范化的数据存储:一个更快、更简单(易于使用)的数据库,您可以将完整的对象图放入并非常快速地读取它们。与 SQL + ORM 相比,这非常容易使用。一时间我真的被震撼了。
但是,随着您的应用程序的开发,一些小事情开始变得更加复杂......
为了使来自其他集合的嵌入数据保持同步,您需要在应用程序级别进行处理。这意味着每当您保存 A 时,您可能需要在其他地方更新 B 和 C。示例:用户 cmets:您希望在每个评论中嵌入基本用户对象。
随着时间的推移,事物 A、B 和 C 的定义会随着应用程序的增长而缓慢变化和发展。
将此与松散类型的语言结合使用,很容易意外保存一个空字符串而不是 null,或者是 null 而不是 undefined。这是最好的情况。通常,您犯的这些小错误会被捕获并导致错误。现在它们将永远保存到您的数据库中,而您甚至不知道自己滑倒了。直到你的应用程序崩溃,因为你的数据是错误的。在你修复了其中的一些之后,你开始非常防御性地编程。小改动现在很难,而且风险更高。
虽然您当然可以推出自己的(任何东西),但在应用程序代码和数据库之间添加一个小型安全网始终是一个好主意。很高兴知道 id 列总是意味着某件事。或者当某些东西被保存时,你肯定会遇到 X、Y 和 Z 的检查。
或者当您更改用户名时,它实际上会更新您的 cmets。
Mongoose 提供的验证、查询构建器、保存前/保存后挂钩、种群和其他好东西将为您省去很多麻烦。
归根结底,您需要在您想要投入的努力与您感到满意的正确性之间取得平衡。虽然我从普通的 mongo 访问中获得了很多价值,但拥有 mongoose 也是 Mongo 和完整的 SQL/ORM 组合之间的一个很好的权宜之计。
【讨论】: