MongoDB - каким путем я должен установить отношения?

Question

В настоящее время я экспериментирую с Node.js и MongoDB, чтобы создать приложение для моей свадьбы. В настоящее время я работаю над планировщиком стола для свадебного завтрака, который будет работать как доска Trello. Каждый гость будет предметом, а каждый обеденный стол будет вести себя как список трелло. Поэтому, когда вы построите, мы можем просто перетаскивать гостей из неназначенной стопки на определенную доску в стиле трелло, которая будет выделять им позицию за столом.

Каждый стол для завтрака рассчитан на нескольких гостей, и гость может сидеть только за одним столом. Меня немного смущает, включать ли «таблицу» в качестве внешнего ключа в гостевую модель или наоборот.

Наличие «таблицы» в качестве внешнего ключа позволяет мне легко запрашивать гостей, у которых в настоящее время нет таблицы. С другой стороны, наличие гостей в качестве внешних ключей в модели «таблица» позволяет мне легко запрашивать таблицы, которым еще не назначены гости.

Мне потребуется выполнить оба вышеупомянутых запроса, чтобы обновить состояние в React.

Ниже показана моя гостевая схема и ее связь с моделью таблицы:

const guestSchema = new mongoose.Schema({
  firstname: {
      type: String,
      required: 'Please provide the first name of the guest',
      trim: true
  },
  surname: {
      type: String,
      required: 'Please provide the surname of the guest',
      trim: true
  },
  attending: {
      type: String,
      default: 'Awaiting RSVP'
  },
  menu: {
      type: String,
      default: 'Awaiting RSVP'
  },
  allergies: {
      type: String,
      default: 'Awaiting RSVP'
  },
  table: {
      type: mongoose.Schema.ObjectId,
      ref: 'Table',
  }
});

const tableSchema = new mongoose.Schema({
  name: {
    type: String,
    required: 'Please provide the name of the table',
    trim: true
  },
  capacity: {
    type: Number,
    required: 'Please provide the capacity of the table',
  }
});

Answer 1

Я бы сохранил номер таблицы на человека, хотя я не знаю, что у вас возникнут какие-то проблемы в другом направлении.

При разработке базы данных дети должны (как правило) иметь ссылку на своих родителей, а не наоборот. На мой взгляд, стол «владеет» людьми, которые сидят за столом (отношения один-ко-многим), а не людьми, владеющими частью таблицы, что делает таблицу родителем.

Еще одним преимуществом будет единая точка обновления, если кто-то перемещает таблицы. Вы просто обновите гостевую запись, а не удаляете ее из одной таблицы и добавляете в другую.

Что обычно помогает мне при моделировании решений, так это смотреть на проблему в более широком масштабе. Представьте себе создание базы данных о том, где живут люди. Вы хотели бы иметь людей, которые имеют свойство адреса улицы и поле, которое ссылается на запись состояния, которая имеет поле, которое ссылается на запись страны. Как только вы обобщаете и масштабируете свою проблему, обычно есть более ясное решение.

Если вы воспользуетесь этим подходом, вы можете использовать агрегирование, чтобы определить, какие таблицы не заполнены.

db.guests.aggregate([ {$group : { _id: '$tableId', seatsFilled : {$sum : 1}}} ])

Answer 2

Это просто другой подход, поскольку вы пытаетесь использовать модель документа в качестве основного объекта и несколько коллекций для различных типов. Это также звучит так, будто на столе может быть только столько людей, а каждый человек может быть только на столе.

В таблице может быть много людей, но в таблице может быть уникальный человек

Человек может быть только частью одного стола.

Лично я не думаю, что для ВАШ варианта использования является проблемой наличие ссылки как в таблице, так и в человеке. Было бы глупо пытаться создать таблицу мостов, и NoSQL не обязательно соответствует тем же правилам нормализации для баз данных SQL. При этом более масштабные приложения могут отличаться. Я думаю, что проблема людей в общем заключается в том, что каждый хочет использовать архитектуру высокого уровня и сложную теорию в случаях использования, которые не принесут ей никакой пользы. Поиграйте и посмотрите, что работает, и просто изучите, как ваше решение может масштабироваться в гораздо большем / сложном наборе данных.

Даже если бы на вашей свадьбе было 1000 человек, я сомневаюсь, что это будет проблемой. В качестве справки, просто ради общей практики, хорошо подумать о том, какую базу данных вам нужно использовать для вашего типа данных. Если у вас много реляционных данных, MongoDB может быть выполнена таким образом, но производительность может упасть по сравнению с традиционной базой данных SQL из исследований и работ, которые я выполнял в прошлом. Этот материал должен быть продуман до выбора вашей технологии.

Поскольку вы используете Mongoose, вы можете легко ссылаться на другие объекты через ObjectId, и запросы должны быть простыми.

Если вы ударите его по пользователю, вы можете запросить таблицу по таблице ref в коллекции Users. Это не обязательно должно быть в обоих направлениях, и, поскольку у вашего пользователя может быть только одна таблица, кажется, что нет необходимости делать оба варианта.

Думайте об этом так. Например, у вас может быть таблица с 10 пользователями. Когда вы смотрите на пользователя, вы хотите узнать, за каким столом он находится. Это означает, что когда вы запрашиваете коллекцию таблиц, вы должны запрашивать каждую запись, которая может иметь другой массив пользователей. Поиск, вероятно, намного медленнее, чем поиск, который просматривает отдельное свойство для каждого пользователя.

Просто хотел предложить понимание того, как вы можете это сделать. Я не буду говорить, что является лучшим, потому что могут быть другие переменные, которые я не учитываю. Тем не менее, я бы, вероятно, просто положил это на пользователя. Выясните, что работает лучше для вас.