经过大量研究,我以流畅的方式编写了我的架构。它帮助我保持了应用程序的可扩展性,并为多种通知功能提供了最佳解决方案。
NotificationSchema = new Schema({
sender: {type:mongoose.Schema.Types.ObjectId, ref:'User'}, // Notification creator
receiver: [{type:mongoose.Schema.Types.ObjectId, ref:'User'}], // Ids of the receivers of the notification
message: String, // any description of the notification message
read_by:[{
readerId:{type:mongoose.Schema.Types.ObjectId, ref:'User'},
read_at: {type: Date, default: Date.now}
}],
created_at:{type: Date, default: Date.now},
});
为什么这对我来说是最好的通知架构:
让我们解释一下架构,我在这里写了这个解决方案可以做什么。
Sender:我必须将 sender 字段保存为一个对象,该对象被称为人口的用户集合。因为通知通常发生在单个操作中,我的意思是它可以从单个人的活动中创建。所以,发送者就是发送这个通知的人,通知的来源。
接收者:我将接收者字段保存为对象数组,如果人口需要,该对象将被引用到用户集合。接收者可以是一个人,也可以是多人。因此,receiver 字段将保存收件人的 ID。
消息:消息字段用于保存通知消息的详细信息。
Read_by:read_by 字段是一个包含两个对象属性的数组。此对象包含 readerId(user-id) 和 read_at(看到的日期时间)。 read_by 数组减少了许多工作,并提供了更高级的选项来使用。它将用于跟踪每个收件人的查看时间来跟踪。因此,通知发送者可以跟踪哪个接收者在何时阅读了该消息。
Created_at:此字段仅保存通知创建日期和时间。
因此,此架构对于发出一对一和一对多的通知非常有用。这就是为什么我认为它是 MongoDB 数据库的最佳通知模式。