Я просто хотел бы подтвердить преимущества использования виртуальной системы mon goose на Schema
при двухсторонних ссылках по сравнению с сохранением массива ObjectId
s на обеих схемах. , Пример последнего метода будет выглядеть примерно так:
const ActorSchema = new mongoose.Schema({
name: String,
movies: [{ type: Schema.Types.ObjectId, ref: "Movie" }]
});
const MovieSchema = new mongoose.Schema({
name: String,
actors: [{ type: Schema.Types.ObjectId, ref: "Actor" }]
});
const Actor = mongoose.model("Actor", ActorSchema);
const Movie = mongoose.model("Movie", MovieSchema);
Актер может быть во многих фильмах, а у mov ie может быть много актеров. Возможно, это не лучший пример, но теоретически массивы movies
и actors
могут расти без ограничений, что является MongoDB anti-pattern .
Альтернативой может быть использование виртуальный на одной из двух схем, в этом примере на ActorSchema
.
const ActorSchema = new mongoose.Schema({
name: String
});
// The virtual
ActorSchema.virtual("movies", {
ref: "Movie",
foreignField: "actors",
localField: "_id"
});
const MovieSchema = new mongoose.Schema({
name: String,
actors: [{ type: Schema.Types.ObjectId, ref: "Actor" }]
});
const Actor = mongoose.model("Actor", ActorSchema);
const Movie = mongoose.model("Movie", MovieSchema);
Это мое понимание , почему имеет смысл использовать виртуальный здесь.
Если мы сохраним массив ObjectId
s на каждом Schema
, каждый из которых ссылается на другой, мы рискуем, чтобы они выпали из syn c.
Когда массив может расти без ограничений, он рискует достичь предела размера документа. Поскольку виртуальные объекты вычисляются свойств, а не хранятся , мы можем уменьшить размер нашего документа.
Есть ли другие причины? И правильно ли я думаю о виртуальном шаблоне?
PS Преимущества использования Virtuals в понедельник goose - хороший ответ, но в меньшей степени связан с преимуществами двусторонней связи. ссылки.