Как хранить данные опций в монго? - PullRequest
3 голосов
/ 03 марта 2012

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

Гнездится

Arabian
Quarter Horse
Saddlebred

Регистраторы

AQHA
American Arabians

Возможно, существует 5 или 6 различных коллекций, которые варьируются от 5 до 15 элементов.

Как лучше всего поместить их в Монго? Прямо сейчас у меня есть отдельная коллекция для каждой группы. Это коллекция пород, коллекция регистраторов и т. Д.

Это лучший способ, или было бы разумнее иметь один сбор статических данных с полем типа, определяющим тип параметра?

Или что-то еще совершенно другое?

Ответы [ 3 ]

3 голосов
/ 03 марта 2012

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

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

2 голосов
/ 27 декабря 2012

MongoDB не имеет схемы, а также JOIN не поддерживается. Таким образом, вы должны выйти из СУБД и нормализации, учитывая тот факт, что это чисто другой тип базы данных.

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

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

ПРИМЕЧАНИЕ: При встраивании коллекций в качестве поддокументов всегда следите за тем, чтобы никогда не превышать предел в 16 МБ. Это ограничение (на данный момент) для каждой коллекции может принимать в MongoDB.

Динамические основные / справочные данные
Старайтесь хранить их в отдельной коллекции, поскольку основные данные часто меняются.

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

Таким образом, НЕТ предложенного лучшего способа, он всегда меняется в зависимости от ваших потребностей, и дизайн может идти в любом направлении.

2 голосов
/ 26 декабря 2012

Я считаю, что создание нескольких коллекций влияет на размер коллекции? (что-то о MongoDB, создающем файл коллекции на диске, в два раза больше, чем предыдущий файл [db.0 = 64 МБ, db.1 = 128 МБ и т. д.)

Вот что я могу придумать:

1. Хранится как единая коллекция

Преимущества здесь:

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

У меня есть нечто похожее на проект, над которым я работаю. У меня есть категории и подкатегории, хранящиеся в одной коллекции. Вот дамп JSON / BSON в качестве примера:

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

{
  "status": {
    "code": 200
  },
  "response": {
    "categories": [
      {
        "cat": "Taxi",
        "_id": "50b92b585cf34cbc0f000004",
        "subcat": []
      },
      {
        "cat": "Bus",
        "_id": "50b92b585cf34cbc0f000005",
        "subcat": [
          {
            "cat": "Bus Rapid Transit",
            "_id": "50b92b585cf34cbc0f00000b"
          },
          {
            "cat": "Express Bus Service",
            "_id": "50b92b585cf34cbc0f00000a"
          },
          {
            "cat": "Public Transport Bus",
            "_id": "50b92b585cf34cbc0f000009"
          },
          {
            "cat": "Tour Bus",
            "_id": "50b92b585cf34cbc0f000008"
          },
          {
            "cat": "Shuttle Bus",
            "_id": "50b92b585cf34cbc0f000007"
          },
          {
            "cat": "Intercity Bus",
            "_id": "50b92b585cf34cbc0f000006"
          }
        ]
      },
      {
        "cat": "Rail",
        "_id": "50b92b585cf34cbc0f00000c",
        "subcat": [
          {
            "cat": "Intercity Train",
            "_id": "50b92b585cf34cbc0f000012"
          },
          {
            "cat": "Rapid Transit/Subway",
            "_id": "50b92b585cf34cbc0f000011"
          },
          {
            "cat": "High-speed Rail",
            "_id": "50b92b585cf34cbc0f000010"
          },
          {
            "cat": "Express Train Service",
            "_id": "50b92b585cf34cbc0f00000f"
          },
          {
            "cat": "Passenger Train",
            "_id": "50b92b585cf34cbc0f00000e"
          },
          {
            "cat": "Tram",
            "_id": "50b92b585cf34cbc0f00000d"
          }
        ]
      }
    ]
  }
}

У меня есть вызов к моему API, который получает этот документ (app.ly/api/v1/stationcategories). Я считаю, что с этим гораздо проще кодировать.

В вашем случае вы можете получить что-то вроде:

      {
        "option": "Breeds",
        "_id": "xxx",
        "suboption": [
          {
            "option": "Arabian",
            "_id": "xxx"
          },
          {
            "option": "Quarter House",
            "_id": "xxx"
          },
          {
            "option": "Saddlebred",
            "_id": "xxx"
          }
        ]
      },
      {
        "option": "Registrars",
        "_id": "xxx",
        "suboption": [
          {
            "option": "AQHA",
            "_id": "xxx"
          },
          {
            "option": "American Arabians",
            "_id": "xxx"
          }
        ]
      }

Всякий раз, когда они вам нужны, либо просматривайте их, либо извлекайте конкретные параметры из вашей коллекции.

2. Хранение в виде статического JSON-документа

Это, как упоминал @Sergio, является жизнеспособным и более упрощенным подходом. Затем вы можете иметь отдельные документы для отдельных параметров или поместить их в один документ.

  • Вы теряете здесь некоторую гибкость, потому что вы не можете ссылаться на опции по Id (что я предпочитаю, потому что изменение имени опции не влияет на все остальные ваши данные).
  • Склонность к опечаткам (хотя, если вы знаете, что делаете, это не должно быть проблемой).
  • Для пользователей Node.js : может возникнуть головная боль от require('../../../options.json'), похожая на PHP.

Читатель заметит, что я негативно отношусь к этому подходу, он работает, но довольно негибкий. Хотя мы не рекомендуем использовать соединения без необходимости в MongoDB, ссылки на ObjectId иногда полезны и расширяемы.

Например, если ваш сайт становится популярным в одном регионе мира, и, скажем, люди из Польши начинают составлять 50% посещений вашего сайта. Если вы решили добавить польские переводы. Вам нужно будет вернуться ко всем вашим документам и добавить польские имена (если они есть) в ваши настройки. Если используется подход 1 , это так же просто, как добавить польское имя к вашим опциям, а затем извлечь польское имя из вашей коллекции опций во время выполнения.

Я мог думать только о 2-х вариантах, кроме хранения каждого варианта как коллекции

ОБНОВЛЕНИЕ: Если у кого-то есть положительные или отрицательные стороны для любого подхода, пожалуйста, добавьте их. Мой уклон может быть бесполезен для некоторых людей, так как есть преимущества хранения статических файлов JSON

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...