Я считаю, что создание нескольких коллекций влияет на размер коллекции? (что-то о 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