从关系数据库设计过渡到“非关系型”一直很有意思。
无论如何,
我设置了以下mongoose模型:用户,公司,作业和应用。< / p>
当用户申请工作时,他们的申请与工作相关联。
因此,一种方法是在作业中嵌套对应用程序的引用:
var JobSchema = new Schema({
title: String,
description: String,
applications: [{ type: Schema.ObjectId, ref: 'Applications' }]
});
并在应用程序上存储对用户和作业的引用:
var Application = new Schema({
resumeFile: String
user: { type: Schema.ObjectId, ref: 'User' }
job: { type: Schema.ObjectId, ref: 'Job' }
});
很好,让任何工作的申请人都很简单。
接下来的问题是,如何让申请人获得用户?
我还必须将应用程序存储在用户身上:
var User = new Schema({
name: String
email: String
applications: [{ type: Schema.ObjectId, ref: 'Applications' }]
});
但是,现在 - 如果删除了申请文件(无论出于何种原因),我仍然会在“工作”文档和“用户”文档中对该文档进行“引用”。因此,我需要找到用户和作业,获取两个文档...找到正确的引用...从嵌套数组中删除它们...然后再次保存这两个文档。
与具有表连接的关系数据库相比,这看起来非常荒谬,其中整个引用无意义甚至都不存在。关联是隐含的。
所以我想知道,这是唯一的方法吗? (故意修辞,但我没有更好的解决方案)。
非常感谢建议以及答案。
答案 0 :(得分:1)
就我个人而言,我可能会将其作为嵌入式架构,因为它可能适合您的使用模式。一些要点:
应用程序作为数组。经过一番考虑后,谁会有100或甚至1000的申请。即便如此,他们真的都需要保留吗?
简要信息。这似乎会显示出很多东西,因此保持嵌入的东西似乎是值得的。
作业详情作为链接对象。作业(或广告)可能包含更多信息,但在显示用户摘要时不需要这样做。由于所有文档ID都存在,您仍然可以提取链接的作业。
反向应用。无需在作业上存储关联的应用程序,用户之间存在用户与作业关联。所以你仍然可以获得所有应用程序,尽管是在一个单独的查询中。
var jobDetailSchema = new Schema({
// All the details of the job
});
var applicationSchema = new Schema({
resumeFile: String,
job: {
title: String,
shortDescription: String,
jobDetail: { type: Schema.ObjectId, ref: 'JobDetail' }
}
},{ _id: false});
var userSchema = new Schema({
name: String,
email: String,
applications: [applicationSchema]
});
var User = mongoose.model( "User", userSchema );
var JobDetail = mongoose.model( "JobDetail", jobDetailSchema );
所以是的,这与关系方法不同,但这不是关系数据存储区。
如果工作岗位消失,你需要做一些清理工作吗?是的,但这并不是太多的维护,即使链接消失也不应该是一种痛苦。您是否因为工作被拉动而丢失应用程序详细信息?可能不是,所以这或多或少是正确的。
如果整个应用程序嵌入式东西吓到你太多,那么好吧,继续使用引用并覆盖所有调用populate
的查询。但一般模型仍然远离一个非典型的“多对多”建模案例。只是把事情弄平了一点。
正如智者所说,“你必须忘记,你所学到的东西”,年轻的padawan。拥抱一个新世界,而不是坚持旧世界。但如果它不适合您的项目,那么它就不是正确的工具。
答案 1 :(得分:0)
与具有表连接的关系数据库相比,这看起来非常荒谬,这整个参考废话甚至都不存在。 关联是隐含的。
Mongodb不是关系型的,你不能指望非关系数据库的行为类似于关系数据库,所以是的,你需要手动清理你的数据,或者按照预期使用mongodb,这意味着在应用文档中嵌入应用程序并删除任何引用从用户申请。
现在一些ODM(如PHP中的Mongo ODM)将负责清理,因为您可以在代码中应用“约束”并级联删除,更新等等...... Mongoose不会这样做。< / p>
如果您的数据是关系型的,请使用RDBMS,如果您编码的平台上没有框架可以为您处理关系,请不要使用MongoDB。