Чтобы нормализовать MongoDB / Mon goose, чтобы упростить схему GraphQL?

Question

Предположим схему продавца с более чем 60+ встроенными полями, представляющими отношения 1: 1 и 1: M, и смесь встроенных документов и ссылок на документы, например, «директор», «адреса» и «банковские счета». Мы определенно не храним ничего большого, что превышало бы ограничение в 16 МБ). По сути, у вас есть типичная, лучшая практика, ненормализованная схема No SQL.

Друг предлагает вам разбить ранее встроенные поля, такие как «директор», «адреса» и «банковские счета» в их собственную схему и коллекции. У каждого из них есть добавленное поле sellerId, указывающее на его владельца / продавца.

Аргумент моего друга заключается в том, что благодаря этому наши определения типа GraphQL и схемы ввода становятся проще для определения и управления - учитывая более 60 полей для Продавец? Таким образом, вместо создания единого массивного определения «тип» и «тип ввода» более 60 полей в нашей схеме GraphQL, он теперь может разбивать «директоры», «адреса» и «банковские счета» на их собственные типы и определения входных данных

Q1. Есть ли в этом действительный лог c? Чтобы нормализовать MongoDB для упрощения типа схемы GraphQL и обработки ввода?

Q2. Предполагая, что мы разбили те вышеупомянутые, ранее внедренные поля, которые в большинстве случаев являются устаревшими и редко запрашиваемыми данными, действительно ли это плохо для нормализации в MongoDB?

Да, я знаю, если вы тоже нормализуете много, почему вы не используете RDB / SQL ?? Я предполагаю, потому что знание JavaScript, работа с JSON и понедельник goose ORM, с ограниченными ресурсами, делают его привлекательным хранилищем данных.

Answer 1

Базовый источник данных не должен управлять вашей схемой - потребности клиентов, использующих ваш API.

Кроме того, запрашиваете ли вы встроенный документ или используете populate / $lookup для извлечения ссылочных документов возвращаемые данные будут иметь одинаковую форму, поэтому неясно, какое отношение это различие имеет к вашей схеме GraphQL. Более того, форма данных, возвращаемых вашим источником данных, не должна соответствовать вашей схеме. Даже если у вас плоская структура данных, например:

{
  "name": "...",
  "addressLine: "...",
  "city": "...",
  "state": "...",
  "zipCode": "...",
}

Ваш тип GraphQL может выглядеть следующим образом:

type User {
  name: String
  address: Address
}

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

Возможны проблемы производительности и стоимости, которые должны учитывать ваше решение о нормализации или денормализации данные - или вам следует вообще отказаться от MongoDB. Но ваша схема не должна быть фактором вообще.