Ещё хужее. :)

ЗЫ. Вон, в 8-ю версию что-то подобное человеческому EXPLAIN ANALYZE завезли. Глядишь, оно станет для развлечения с данными потребным. :)

там наверно от движка зависит, или от версии, я чет сомневаюсь что они настолько классные что соблюдают совместимость всех движков на всех версиях )))

Есть вопрос по миграции (хотя строго говоря - не совсем) в PostgreSQL с MongoDB. Посмотрел имеющиеся туториалы - в основном они из серии "возьми такую-то утилиту и всё готово". Но моя задача стоит в том, чтобы не тупо скопировать ключи документов Mongo и преобразовать их в аттрибуты PSQL, а скорее - в том, чтобы рационализировать схему хранения и возможно, запилить какую-то другую схему отображения в текущем приложении.
Может быть есть какие-то гайдлайны, которые позволяют не наступить на какие-то грабли, не строить лишних велосипедов и так далее?

что не так с монгой? почему возникла задача миграции (оправдана ли миграция рациональными соображениями)?

Не. По факту в MySQL нет физической репликации, там только логическая. Поэтому вот.

Монга - БД, ПГ - СУБД. Вот и вся разница.

я вобще не вас спрашивал

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

Это сложно и будет делаться только вашими силами. Можно сначала как есть переложить в постгрес jsonb и перепиливать приложение под постгрес. Потом работать над схемой и приложением.

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

Если часто менялась схема, то придётся лопатить данные и приводить к единой схеме при переезде с jsonb

Как вариант, можно выгрузить через copy данные из партиции.

Ну, это всё про выгрузки. Я хотел как в оракле, чтоб можно было просто откусить AS-IS табличное пространство с партицией. Без доп нагрузки на БД.

Я прост думал, может есть какой-то FAQ по этому поводу) эх, снова тетрадочка driven development ))) спасибо за ответ )

нет, да и не может быть руководств при подобных миграциях. Хотя план набросать...
1. смотрите на существующие данные;
2. изучаете проектирование реляционных БД (нормализация и вот это вот всё);
3. проектируете схему БД;
....
Всё в ПГ!

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

не видел начало...

но откуда мысль про то, что в nosql отсутсвует схема данных?

покупайте PostgreProEE и будет вам счастье) https://postgrespro.ru/docs/enterprise/12/pgtransfer

или имеется ввиду отсутствие стандратного способа описания?