Question

我对来自MS Sql / Entity框架环境的MongoDb世界相对较新。

我为Mongo感到兴奋，因为：

MongoDb能够在运行时动态更改类/表/集合的形状。

实体框架不能为我提供。

为什么这么重要？

因为我想创建一个通用的广告资源应用，并让产品类/集合/表格动态 ，以便客户添加与其业务无关的字段 < / strong>，例如。 Vin编号，ISBN编号等

现在我开始了解Mongoose以及它如何提供模式，这对我来说有损于上述MongoDb的灵活性。

我已经在几个部分中读到有混合模式这样的动物，但是相对于数据类型而言似乎是动态的，而不是给定类/集合/表的属性集合。

所以这是我的问题：

如果我正在研究开发一个通用的类/集合/表，它可以让客户根据他们想要的业务，动态地包含他们想要的任何字段/属性，我应该放弃mongoose的整个概念吗？

Answer 1

我今天发现了一个可以保证架构的好处：

请允许我接受序言，并说我仍然非常兴奋Mongo允许在我可能需要ti的情况下在运行时重新整形集合的整个想法。如上所述，一个完美的例子是Inventory应用程序，我希望每个客户端添加与其业务相关的相应字段而不是其他客户端，例如需要VIN编号字段的汽车经销商或需要ISBN号字段。

Mongo将允许我创建一个通用表，让客户端在运行时根据自己的意愿为自己的数据库设置它 - SWEET！

但我今天发现架构适合：

如果在另一个不能“重新塑造”的表中，比如一个用户表，我可以为预先确定的字段创建一个Schema并使它们成为必需的，如下所示：

 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!'}
   }
 });

通过从架构中获取所需的相应名字和姓氏，如果用户未包含在插入中，则数据库不会为用户添加任何记录。

所以，我猜两个世界都是最好的：可以重新塑造的表格和通过模式的表格，表格可以是僵硬的。

更好地理解Mongoose Schema

1 个答案: