mongodb - 更好地理解Mongoose Schema

我对MongoDB还比较陌生，来自MS SQL/实体框架环境。
我对Mongo很兴奋，因为：
MongoDB在运行时动态更改类/表/集合的形状的能力。
实体框架没有提供给我。
为什么这么重要？
因为我想创建一个通用的库存应用程序，并让产品类/集合/表是动态的，以便客户添加与他们的业务相关的字段，而这些字段不是每个人都可以使用的，例如vin编号、isbn编号等。
现在我来学习Mongoose以及它如何提供模式，这对我来说有损于上面描述的MongoDB的灵活性。
我在几节中读到，有一种类似混合模式的动物，但相对于数据类型而言，它似乎是动态的，而不是给定类/集合/表的属性集合。
所以这是我的问题：
如果我想开发一个通用类/集合/表，让客户能够动态地将它塑造成包含他们想要的与他们的业务相关的任何字段/属性，我应该放弃Mongoose的整个概念吗？

最佳答案

我今天发现了一个好处，在哪里可以保证一个模式：
不过，请允许我先说一句，我仍然对mongo允许在运行时在需要ti的情况下重塑集合的整个想法感到非常兴奋。如前所述，一个完美的例子是一个库存应用程序，我希望每个客户添加与他们的业务相关的字段，而不是其他客户，例如需要一个车辆识别号字段的汽车经销商，或需要一个ISBN编号字段的书店。
Mongo将允许我创建一个通用表，并让客户机根据自己的愿望在运行时对自己的数据库进行修改-sweet！
但我今天发现一个模式将被批准：
如果在另一个不可“重新调整形状”的表中，例如用户表中，我可以为预先确定的字段创建一个架构并使其成为必需字段，例如：

 var dbUserSchema = mongoose.Schema({
   title: {type:String, required:'{PATH} is required!'},
   FullName: {
       FirstName: {type: String, required: '{PATH} is required!'},
       LastName: {type: String, required: '{PATH} is required!'}
   }
 });

通过从架构中获得所需的各自的名字和姓氏，数据库将不会为用户添加任何记录（如果这些记录不同时包含在插入中）。
所以，我想我们可以从这两个世界中得到最好的结果：可以重新构造的表和通过模式的表，可以是刚性的表。