Кто имел опыт переноса хранимок с Oracle/MsSql на хранимки PostgreSQL?

Расскажите, как оно? Норм, или боль и страдания?

я лично переписывал в ручную но было обидно что нету джобов. Нужно будет через airflow либо через cron в ручную шедулить их

Как нет? pgAgent, pg_cron, мб. ещё чтото. Встроенных нет - ну так тут работает принцип unix: каждое приложение должно выполнять одну задачу.

При переносе с oracle сложности могут возникнуть если активно используются переменные пакета. Также, вложенные функции pl/pgSQL не поддерживает. Вообще, на одном из прошлых pgConf был доклад о том, как для перевода большого проекта на postgresql был написан парсер pl/SQL-кода с генерацией pl/pgSQL. Что-то требовалось вручную доделывать конечно. К сожалению, делать из этого продукт или публиковать код они не планировали.

При переводе с Оракла в Postgresql обычно проще просто тупо все заново переписать с учетом особенностей Postgres

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

Зависит от размеров проекта. Переписать несколько мегабайт кода ни разу не просто.

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

Боль и страдание и из-за хранимое из из-за того что только конченные (сами знаете) кто обмазываются хранимками и код у этих хороших людей это го+++ некоторая коричневая субстанция

Но я конечно допускаю что новые проекты а не родом из 2000-ных могут быть и написаны получше

Т.е. юзать хранимки в PostgreSQL - это в принципе плохая практика?

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

А, ну я про такое и не писал вообще

Нет, отличная практика, и написать бизнес-логику на них — тожэ часто правильное решэние. Тот чел просто хейтер хранимок.

Просто пока не запретили что то, на чем логика приложения написана. Имхо, сами хранимки/функции, сама их суть, моветоном не является. Норм тема.

Хрень

Просто некоторые не могут грамотно декомпозировать систему. Код обработки данных должен быть как можно ближе к данным. И когда из БД на уровень приложения начинают данные тянуть, потом их меняют, и персистят, с удивленными лицами, почему данные не консистентные - ты начинаешь говорить про mvvc, про locks и т.д, и в лицах программистов server side видишь удивление, то понимаешь - А может взять грамотного db developer, который все это знает, вникнет в логику и просто для критичных бизнес кейсов предоставит хранимки, а server side Разрабы из dtoшки в dtoшку переложат? :)))

Первая причина делать хранимые процедуры — не перекачивать объёмы необработанных данных из СУБД в приложение. Вторая причина — язык программирования приложения тоже может поменяться. Третья, вы её называли, — в хранимках легче управлять изоляцией транзакций. Ещё? Но при этом мы не хотим получить vendor lock на конкретную СУБД. Логичным был бы вариант использовать ORM, который генерит хранимки под данную СУБД. В базе получится говнокод, но у нас останутся приличные исходники, которые можно запустить на другой СУБД. Для критичных по быстродействию мест надо будет переписать на нативный PL/SQL (при этом не выкидывая "универсальную" версию, продолжая поддерживать её в актуальном состоянии). Что вы про это думаете? Какой бы рецепт посоветовали для проекта, который только начинается? (Предполагая, что в проекте будет много бизнес-кода, который пишут прикладные программисты)

Вендор лок - несуществующая проблема, если ваша база опенсорсная

Вы предлагаете получить только те возможности, которые доступны во всех ведущих СУБД, а от остальных отказаться?

Я предлагал для 5% критичных мест писать на нативном языке, но при этом иметь для этих частей workaround, который делает неоптимально, но универсально. Просто при переводе с одной СУБД на другую приходится сталкиваться с тем, что спец-возможности СУБД были задествованы даже там, где без этого моно было обойтись

Ваш орм сам станет субд, если будет уметь всё и цеплять бекендом любую другую субд, это значит запретят его :)

Ну то есть если так подходить к ситуации, то ваш орм - постгрес, а при миграции на другие базы таблички в них просто надо перемещать по FDW, перкписывать ничего не надо, неоптимально но универсально

>Третья, вы её называли, — в хранимках легче управлять изоляцией транзакций. На самом деле -- гораздо тяжэлее. >Но при этом мы не хотим получить vendor lock на конкретную СУБД. Если вы этого не хотите -- то с хранимками вам будет тяжэло, что уж там. >Какой бы рецепт посоветовали для проекта, который только начинается? Не знаете, что пилить -- пилите трёхзвенку. Выбор трёхзвенки редко выглядит шоу-стоппером или критической ошыбкой в дальнейшэм. Это не значит, что трёхзвенки всем хорошы -- выбор любой другой архитетуры часто обоснован. Но они обычно достаточно приемлемы, и их можно выбрать если всё непонятно.

Трёхзвенка в контексте обсуждаемого вопроса означает "максимум логики в application server, минимум в хранимках"?

Да, максимум логики в application server. Который только для логики, он не делает презентацыю и ввод данных как таковой. И дажэ определённый state и изоляцыю транзакцый можно в application server.

Не советую, у того же oracle_fdw хреновая производительность на вставку в oracle, скорее всего из-за того, что данные передаются по одной строке. Хотя мб. в последней версии и починили, но года 3 назад было всё плохо. Будто этого мало, у oracle есть баги в индексах (вроде) при работе в режиме serializeable, с которым работает oracle_fdw.

так просили же универсально и не обязательно быстро

Так абстрактно не смогу ответить. Мы же программисты, работаем для того, чтобы автоматизировать бизнес задачи😊 у всего есть требования, затем люди, которые эти требования качественно выполнят. Если нет профильных разрабов на БД, делать утверждение, что код надо писать именно там и нигде иначе, рискует убить проект сразу, т.к работать надо с теми ресурсами, что есть. Если же говорить про идеальный мир, с зоной компетенции, обязанностей и ответственностей, то среднестатистически у разраба БД будет скил выше по работе с базами, чем у чувака, который кодит на Java или c#. Понятно, что и они могут быть порой круче db developerов профильных, но все же. В итоге, если есть критичные по целостности и консистентности данных сценарии у бизнеса, я бы их пилил как можно ближе к данным и профильными спецами, включая разграничения политик доступа и т.д. Что касается orm, то лично мне он не нравится. На Java того же Mybatis или Querydsl достаточно вместо hibernate или EclipseLink, иначе начинаешь решать не проблемы БД, не проблемы приложения на Java, а ограничения orm на ровном месте. Бизнес часто не понимает это и в принципе я поддерживаю. Если есть вариант взять более гибкое решение без проблем, зачем тратить деньги на решение пустых проблем. :) В итоге: я бы брал open source БД, тот же Postgres, в идеале хотя бы 2 профильных db developer'ов, остальных ребят на server side java, например. Orm не юзал бы

А то, что serializeable by design подразумевает, что вам, возможно, придётся выполнить rollback и заново повторить, не пугает? При том, что на стороні postgresql у вас обычный read committed, от которого такой подставы никто не ожидает (есть небольшая вероятность deadlock-а, но при правильном подходе к блокировкам, его можно исключить в большинстве случаев).

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

Кстати, под java jdbi довольно хорош.

Ну так в чём проблема просто написать под каждую БД код? Это принесёт гораздо меньше страданий, если требуется код максимально близкий к данным.

а вы с кем сейчас разговариваете?

Посмотрите опыт lingualeo, была статья на Хабре, как они огребли от этого

У нас механизмы Spring Data для этих целей😊

А где про огребли? Я видел только что они повышение нагрузки в 5 раз спокойно перенесли именно с этим подходом.

Если разработчики сервер-сайда не знают про локи, транзакции и т.п. - то таковых нужно поменять на тех, кто знает. Идея "разместить логику ближе к данным" и предоставить наружу интерфейс из набора функций кажется хорошей только на первый взгляд, несколько раз видел такой подход на практике - незамедлительно после ухода первого "грамотного db developer, который все это знает", который писал первую версию этих самых хранимок код превращается в ужасное УГ, кол-во ХП начинает расти как на дрожжах, а знания о том, что какая из них делает - стремительно утрачиваются. Если у вас есть достаточный запас "грамотных db developerов, которые все это знают" то, наверное, это может сработать. Но проще заменить тех одров, которых вы почему-то называете "server side разработчиками" на настоящих, которые в курсе про транзакции, уровни изоляции, mvcc, локи и пр.

потому и написал, что минимум 2=) Чтобы не получилось такого, что один уходит и некому поддерживать. Что касается - "Заменить на тех, кто знает", тут двоякая ситуация. Раньше были FullStack разработчики в основном, кодили и Front-End и Back-End (Application Code + DB Code). В какой-то момент стало понятно, что эффективнее взять профильного Front-End, чем пытаться найти Fullstack, который будет круто знать и как Front-End, и как Java (неважно, какой язык, просто для примера), и также круто шарить в базах. Ну не найдёте вы такого спеца на рынке, либо за ЗП на 50% выше рынка, но это плохо по причине, что у вас один человек будет за всё отвечать и работа не будет параллелиться. Короче, проще найти профильного Front-End и профильного Back-End. Но вот почему то решили, что разделение надо закончить на отделении JavaScript/TypeScript от всего остального, а Application Code + DB Code пусть один продолжает кто-то кодить. На мой взгляд это не совсем правильно, хотя это явно сейчас распространено.