MongoDB 是无模式的，这意味着集合（关系数据库中的表）可以包含不同结构的文档（行）——例如，具有不同的字段。
我是 Mongo 的新手，所以我决定使用 Mongoose，这会让事情变得更容易一些。阅读guide：
定义你的架构
Mongoose 中的一切都以 Schema 开始。每个模式映射到一个 MongoDB 集合并定义其中文档的形状 收藏。
注意最后一句。和MongoDB的无模式哲学不冲突吗？或者可能是在 99% 的情况下，我想要一组相同结构的文档，所以在介绍性指南中只讨论了这种情况？ Mongoose 甚至允许我创建无模式集合吗？
【问题讨论】：
MongoDB 不需要模式，但这让很多具有标准 SQL 背景的人感到困惑，因此 Mongoose 旨在尝试弥合 SQL 和 NoSQL 之间的差距。如果您想维护具有不同文档类型的集合，则绝对不要使用 Mongoose。
如果您对 MongoDB 的无模式特性感到满意，则没有理由向 MongoDB 添加额外的抽象和开销，这正是 Mongoose 肯定适用的。
【讨论】：
Mongoose 的目的是使用 Schema，您可以使用其他数据库驱动程序来利用 MongoDB 的无模式特性，例如 Mongoskin。
如果你想利用 Mongoose 的 Schema Design 并创建一个异常，你可以使用：Mongoose Strict。
根据文档：
strict 选项（默认启用）确保传递给模型构造函数但未在我们的架构中指定的值不会保存到数据库中。
【讨论】：
NoSQL 并不意味着没有架构。这意味着，数据库不控制模式。例如，使用 MongoDB，您很难找到任何确定文档中的字段是字符串、数字或日期的内容。数据库不在乎。您可以将数字存储在一个文档的一个字段中，也可以存储在同一集合中的另一个文档中，并且在同一字段中，您可以存储一个字符串。但是，从编码的角度来看，这可能会变得很麻烦，而且是不好的做法。这就是为什么您仍然必须定义数据类型的原因。因此，您仍然需要某种模式以及为什么 Mongoose 提供并且实际上强制执行此功能。
现在在概念层面更高，NoSQL 的主要概念是将模式放在代码中，而不是放在 SQL 命令的某些文件中，即不告诉数据库在数据类型和模式方面将由数据库。因此，您不需要在数据库模式上拥有迁移文件/路径和版本控制，而只需拥有自己的代码。例如，ORM 也试图解决这个问题，他们通常有自动迁移系统。
ORM 还试图避免 Object Relational Impedance Mismatch 问题，而 MongoDB 完全避免了这个问题。好吧，它本身没有关系，所以这个问题是出于必要而避免的。
回到架构，使用 MongoDB 和 Mongoose，如果您或您的团队中的一个人对代码中的架构进行了更改，那么您的所有其他团队成员需要做的就是让数据库使用它新代码。瞧，架构是最新的并且可以工作。不需要也拉入较新的迁移文件的副本（以确定数据库的新模式），然后必须在（副本）数据库上运行它来更新它，只是为了继续编程。无需在多个地方更改架构。
因此，最后，如果您可以想象您的架构始终（仅）在您的代码中，那么对具有数据库持久状态（如 MongoDB）的应用程序进行更改会更简单，甚至更安全。 （更安全，因为代码和架构不会不同步，因为它是一回事。）
【讨论】：