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

https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-1 (там ещё в конце ссылки) https://docs.mongodb.com/manual/applications/data-models/

Универсальных рецептов нет. Плюс документных хранилищ что в них можно писать что угодно, а уже потом разбираться что с этим делать. Минус — в них можно писать что угодно и потом придётся разбираться что с этим делать. Если есть возможность, то писать так, как вы будете читать. Тогда не будет очень больно.

Доку я читал. Но у меня немного другая история У меня динамическая таблица с настройкой отображения - нужно получить по апи список полей - задать им человекочитаемые алиасы и привязать к блокам для отображения.

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

Доку я читал. Но у меня немного другая история У меня динамическая таблица с настройкой отображения - нужно получить по апи список полей - задать им человекочитаемые алиасы и привязать к блокам для отображения.

Вебинары смотрели?

Струтуру-то я организовал, но таблица api_config начала разрастаться и знает и о настройках подключения и о настройках вывода

И есть предположение что надо разбивать ответсвтенность.

Смотрите вебинары

Начните с первой ссылки на блог

Прочитайте три части, потом смотрите вебинары которые в подвале поста в блоге

Потому что это не к монге вопрос, а к вам.

Документные хранилища позволяют плавно регулировать степень нормализации/денормализации данных

И выбор за вами, а точнее за вашими паттернами доступа

Ещё раз повторю: основная идея писать так, как вы будете читать. Т.е. по возможности не читать лишнего и не делать сложных трансформаций со склейкой данных из нескольких коллекций.

Ещё раз повторю: основная идея писать так, как вы будете читать. Т.е. по возможности не читать лишнего и не делать сложных трансформаций со склейкой данных из нескольких коллекций.

Хм а вот эту задачу коллекция как-раз таки и выполняет.

Благодарю.

ребят, вопрос ,возможно, по Го, но тем не менее, есть какой-то устоявшийся паттерн работы с монгой в долгоиграющем приложении, частые запросы, каждый из них транзакция я сделал следующим образом: 1) есть канал с операциями, куда отсылаются функции которые принимают в аргументе sessionContenx и возвращают error 2) при инициализации приложения, создается цикл по этому каналу 3) при поступлении данных в канал забирается функция, создается сессия, создается транзакция 4) вызывается функция с аргументом созданного контекста, если вернулась ошибка вызываем abortTransaction, иначе commit вопрос: по какому принципу выстроить политику retry? проблема в том, что не могу пустить весь вызов на 2й круг, поскольку в пробрасываемой функции возможна запись в канал к которому нет доступа?

Приперся снова с вопросом по монге Есть массив episodes: [{ type: Schema.Types.ObjectId, ref: "Episode" }], Который по идеи должен хранить только: [ObjectId("5c58552e04a97202de2a6c4a"), ObjectId("5c58552e04a97202de2a6sas")] Но при вставке вставляется объект вот такого вида

Всем привет. Помогите пожалуйста с проблемой, бьюсь битый час

Кто нибудь? Я что-то делаю не правильно? Пытаюсь достичь связи 1 ко многим

а поля number sequence это тиап из Episode?

Да

Кто нибудь? Я что-то делаю не правильно? Пытаюсь достичь связи 1 ко многим

храните id родителя в дочерних объектах, а не в родителе

А как я потом подгружу эпизоды, из родителя если у родителя не будет айди на эпизоды?

по id родителя

db.episodes.find({season_id: OID})

там ж монгус

он сам все делает

ну значит в монгусе направление отношений не в ту сторону обращено

Season has many episodes. Episode belongs to season

Я через мангуста И делаю так: await Show.paginate({}, {populate: { path: "episodes", select: "sequence" }}, (err, res)

populate работает при выборке, а не при сохранении

Это, я уже выборку делаю, показываю как

И вот в шоу у меня будет чистый массив из ObjectId, то все подгружает прекрасно

покажите как заполняете sequence

И вот в шоу у меня будет чистый массив из ObjectId, то все подгружает прекрасно

это крайне неудачный паттерн

если это так делает монгус, монгус надо выбросить, он сломан

идеалогически

а почему бы и нет?

> покажите как заполняете sequence sequence - просто массив объектов. Он статичный заполнялся раз, когда был парсинг. Я его не заполняю > если это так делает монгус, монгус надо выбросить, он сломан Подскажите каким образом мне лучше всего организовать связь 1 ко многим? В чем мой выбор ошибочен?

Есть эпизоды, есть шоу. У шоу лежит массив с айдишками эпизодов. Разве это плохо? И почему плохо?

потому что это массив

и это уже проблема

начиная с того что в массиве элементы никто не запрещает дублировать

заканчивая тем, что индексы по массивам это не тоже самое что индексы по полям

Им невозможно задублироваться

ваше утверждение ложно

> заканчивая тем, что индексы по массивам это не тоже самое что индексы по полям можно подробнее пожалуйста?

sequence - просто массив объектов. Он статичный заполнялся раз, когда был парсинг. Я его не заполняю вот тут может и быть проблема, хотя давно уже с монгусом не игрался, но прям чую что там вы должны явно задават ьсписок id, а не просто фигачить объекты

массивы в bson это поддокументы, где ключом является «индекс». как следствие вы сразу теряете covered queries

С чем лучше монго готовить в ноде?

то что вам надо назвается не ref а https://mongoosejs.com/docs/subdocs.html

не знаю

> массивы в bson это поддокументы, где ключом является «индекс». как следствие вы сразу теряете covered queries аргумент. Принял во внимание

т.е. источник связи в виде дочерного документа это самый логичное и направление отношения

второй момент: если у вас внезапно появится много детей, вы можете уперется в лимит по размеру документов.

> то что вам надо назвается не ref а https://mongoosejs.com/docs/subdocs.html Дело в том что от вложенных документов я и убежал. Потому что, выходит что у меня эпизоды могут расти безгранично. А где-то читал что в монго плохо хранить большие массивы, которые постоянно меняют свой размер

это устаревшая информация

но есть другая проблема: размер документа ограничен

То есть могу смело делать сабдокументы и не переживать что длинна массива сабдокументов может расти безгранично?

я бы ввёл понятие сезона, и у же в нём бы хранил эпизоы

а из сезона бы ссылался на шоу

Бесконечно, я имею ввиду что в одном шоу может быть 0 эпизодов и хранится пустой массив. А в другом 10 тысяч эпизодов

так как есть шоу с огромным количеством эпизодов

но обычно сезон ограничен несколькими десятками эпизодов

Ага, разбивать еще больше. В начале про это и думал

Бесконечно, я имею ввиду что в одном шоу может быть 0 эпизодов и хранится пустой массив. А в другом 10 тысяч эпизодов

какая информация хранится в описании эпизода?

Это абстрактный пример

вообще храните так, как это будет отображатся

С сезонами и эпизодами

например в случае с myshows, там более логично хранить эпизоды отдельно

> какая информация хранится в описании эпизода? Дата, описание, Заголовок

хотя

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

Да

Подводя итоги Если данных будет много, ввести понятие Сезона, и тогда дробить на 3 коллекции? Шоу - Сезон - Эпизод ?

можно остановится на двух: шоу и сезон. А в сезоне хранить эпизоды как вложенные документы

главное чтоб у эпизодов тоже _id был

но вы исходите из того как вы будете извлекать эти данные из базы

Ну сейчас у меня так и есть Шоу - Сезон, у сезона есть _id, и массив эпизодов