Ora2pgpro включена в СУБД Postgres Pro Enterprise, чтобы упростить конвертацию кода СУБД Oracle

В январе этого года компания уже представила поддержку пакетов (наборов функций и процедур) «в стиле Oracle» в СУБД Postgres Pro Enterprise.

Насколько мне известно, Tantor (один из конкурентов Postgres Pro) тоже предлагает нечто подобное. Интересно, будут ли эти решения совместимы хотя бы по стнтаксису, или это будет такой vendor-specific…

Пакеты сами по себе — достаточно «вкусная» возможность, и с ними логика уровня сервера выглядит намного опрятнее, чем на хранимых процедурах россыпью.

Ну интересно... Оракл еще и интересен тем, что вокруг него всякой бизнес-логики на джаве написали, с этим что делать?

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

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

Есть одна компания, которая до сих пор сидит на Oracle 9i / Windows 2003 Server. Денег нет куда-то уходить. Выливается им это в то, что никто не хочет с этим работать и новые фичи они по сути уже давно не добавляют, барахтаются пытаясь, чтобы не всё сразу сломалось. Недавно базу потеряли, 3 месяца восстанавливали. По сути они на бюджете сидят, поэтому о рынке тут речь не идёт, но это не существование, это жесть.

люди с екселя не уходят пока не бомбанет, а вы про оракл..

логики которая дёргает процедурки? ну вот новость как раз об этом

В оракле можно хранимые процедуры на жаве писать. Может про это речь. Процедура исполняется как бы внутри оракла. Хотя там то же JDBC, но со своими нюансами.

Я не знаю, как хранимые процедуры, но весь ихний Hibernate свелся к некому подобию select * from all_tables, а дальше руками... Работало все это так себе, слезы одни. Может, конечо, программисты такие, но в джавайском мире это даже не удивительно.

У постгреса коннект дорогой, вот и придумывают всякие pg-пулы и pg-боунсы. И работают они плохо, по отзывам. Я ковырял когда-то Net8, когда надо было проксю прикладную для Оракла написать для файерволла. Так там в ответ на коннект на сервер прям в ответной посылке прилетает адрес сервера, куда тебе идти. И он может не совпадать с тем, куда ты пошел изначально. У них балансер нагрузки прям «из коробки», походу. И это тоже большая проблема для постгреса. Приходилось ответ парсить и в пакетном фильтре дырку сверлить (и затыкать после дисконнекта).

работает на базе open-source приложения ora2pg

ora2pg более-менее прилично справляется с переносом таблиц, да и то не всегда удачно. Что же касается процедур, функций, пакетов и представлений - опыт таков, что уж лучше не полагаться на него совсем и все делать руками, orafce как-то может помочь в портировании.

то, по подсчетам Postgres Professional, поможет заказчикам сэкономить до 50% времени

По статистике 57.83% цифр статистики высосаны из пальца.

Привет так и что у меня тоже самое(

Привет а где таких коней выдают)

С коннектами бы уже как-нибудь поборолись при реальной необходимости. Чай и с ораклом тож коннекшн-пулы используются.

У pg нет оптимизированного ввода-вывода (есть робкие попытки прикрутить directio) и есть insert при update'е с последующим вакуумингом (что, похоже, является неотъемлемой частью архитектуры pg - не будут же все переписывать и добавлять undo, как в оракуле).

Это, пожалуй, самая жесть, на что жалуются субдэшники.

И да, у оракла есть так называемые scan-листенеры, к которым ходят клиенты и спрашивают куда им идти за тем или иным сервисом. После этого клиент идет уже туда, где его обслужат. Используется это, обычно, совместно Oracle RAC и кривокластером Oracle GI (Clusterware).

Используется это, обычно, совместно Oracle RAC и кривокластером Oracle GI (Clusterware).

Вот насчет кривокластера не знаю. Я с этим столкнулся лет 20 назад с самым обычным Ораклом. Типа писали прикладную проксю в составе файерволла, так выяснилось, что через тупой tcp-плаг Net*8 не ходит. Ну так надо было распарсить протокол, что бы в пакетном фильтре дырку просверлить. Ну вот wireshark'ом и увидел, тогда еще он так назывался. Типа идешь на сервер, а тебе в ответе в каком-то лиспообразном формате летит адрес сервера с портом, куда надо идти. Ну хоть в ASCII, и то хорошо. Так что, это общая фича их Net*8, походу.

Лиспоподобная байда - это один из форматов ораклячьей строки подключения. И он - самый популярный в среде ораклоидов.

Что-то типа:
(DESCRIPTION=(ADDRESS=(host=oracle://somedb.example.com)(protocol=TCP)(port=1521)(CONNECT_DATA=(SERVICE_NAME=orclpdb)))

Для меня удивительно, что без RAC есть необходимость ходить за адресом сервиса. С другой стороны, м.б., такая штука используется, например, для Oracle DataGuard, на случай, если клиент сперва пришел на standby, а не на primary. Ну а реализовали всё в клиенте с запасом и единообразно. Ну сходили лишний раз к листенеру - не беда.

А куда валить, когда жопа таки сгорит? LO Calc не лучше.

В январе этого года компания уже представила поддержку пакетов (наборов функций и процедур) «в стиле Oracle» в СУБД Postgres Pro Enterprise.

Пакеты сами по себе — достаточно «вкусная» возможность, и с ними логика уровня сервера выглядит намного опрятнее, чем на хранимых процедурах россыпью.

По сравнению с настоящими PL/SQL пакетами Oracle DB, «пакеты» от это PostgresPro - простенькое подельице. Смотри статью на Habr

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

Функцией инициализации пакета (init-функцией) называется содержащаяся в соответствующей схеме функция на языке PL/pgSQL с именем init, не имеющая параметров и возвращающая тип void.

Глобальными переменными пакета являются переменные, объявленные в функции инициализации.

У EnterpriseDB, мировом ведущем производителе и контрибьюторе PostgreSQL, в его продукте «EDB Postgres Advanced Aerver» с реализацией пакетов подобных пакетам Oracle PL/SQL все намного лучше - документация (через VPN)

С миграцией функционала из Oracle, кстати тоже - есть и методики и давно зарекомендовавшие себя продукты.

PostgrePro идет по их стопам. Но пока не сильно широка. Но на безрыбье и рак - рыба. Пожелаем им успехов. Хотя в последнее время складывается впечатление, что отцы-основатели PostgreSQL больше думают про бабло, чем функционал, имхо. Без бабок нет развития - здесь нет базара, но когда бабки становятся самоцелью - дело швах.

ПС. А я бы был совсем не против, чтобы в каждой реляционной (и не только) базе данных в качестве встроенного и «близкого к данным» языка, был язык - ADA (прообраз для PL/SQL). Нравится мне он своей строгостью.

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

Я тоже в общем-то этого мнения. Я тоже советую, чтобы критические для бизнеса приложения уровня предприятия, работающие на Oracle, пока оставались на Oracle. Потому что функционала версии Oracle DB 19c или 21С, при которых Oracle, под нажимом Госдепа и ЦРУ, отказался сотрудничать с Россией, так вот функционала версии Oracle DB 19c или 21С хватит еще лет на 10 с избытком. А там посмотрим. У нас даже после этого развязаны руки - можно забить на политику кол-ва процессоров. Единственное проблема - обновления ПО. Но здесь, во избежание больш`их проблем, - не обновляться и выходить наружу сети предприятия. Найденные ошибки (а их не так много) исправлять обходными методами (workaround).

На PostgreSQL в настоящее время надо переводить не сильно критичные и нагруженные приложения уровня отдела, депертамента максимум. И коллекционировать негативный и позитивный опыт. Как раз за 10 лет и будет понятно что да как, руку набьем, да и, будем надеяться, PostgreSQL не будет стоять на месте, а будет поступательно развиваться (и лучше бы с стратегическим гос.планированием и поддержкой).

Ну и в аналитических хранилищах Oracle можно менять на Hadoop/Spark, ClickHouse e.t.c

Мне думается, что люди изначально так сделали протокол, что бы потом не придумывать расширения на случай горизонтаьного масштабирования, кластеризации и прочего шардинга и распределителей загрузки. Ну так, значит так, все привыкли и ладно. 30 лет работает, вот и не трогают.

Но на безрыбье и рак - рыба

Сеня, про зайцев - это неактуально. От бизнес-логики в БД нужно было бежать сломя голову еще 15 лет назад, тот, кто пытается сейчас это портировать, а не удалять, совершает огромную ошибку.

и есть insert при update’е с последующим вакуумингом

автовакуум вроде раньше вообще был опцией, которую надо специально включать

в libre можно скриптовать на пейтоне или даже жаваскрипте, мне кажется, это поинтереснее вэбэ

Ваня, не гони. Гонять терабайты данных по сети, да еще с использованием всяких разных ORM - это так себе «удовольствие», это подходит для мелко-пузатых приложеньиц. А для серьезных приложений, бизнес-логика, должна размещаться в одном месте с данными.

Вот странно. Работал и работаю над серьёзными приложениями. Также читаю книги, и смотрю, как делают серьёзные приложения во всяких FAANG/MANGA.

И везде там днём с огнём не найти Oracle. Везде используется ORM. Везде все пишут: «Ни в коем случае не кладите бизнес-логику в базу!».

И тут, в противовес, мнение анонима с форума.

Также читаю книги, и смотрю, как делают серьёзные приложения во всяких FAANG/MANGA.

А сам не пробовал своим умом думать? Попробуй - понравится.

У «великого Oracle» тоже есть причуды, он тоже не безгрешен - это когда он в базе данных размещает не только бизнес-логику, но и пытается генерировать визуальное представление приложения, типа разных APEX-ов, съедая процессорные ресурсы, оплачиваемые как СУБД, как крыло самолета.

Поэтому мой совет - думать всегда своей головой, рассуждать, измерять, делать выводы, а не смотреть на «лучшие практики» от какого-то дяди, которые потом оказываются совсем не лучшими, а наоборот.

… Везде все пишут: «Ни в коем случае не кладите бизнес-логику в базу!»…

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

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

Да, джуны постоянно такое пишут. Они и в бизнес-логике в базе тоже напишут какую-нибудь дичь.

Вряд ли есть хоть одно такое место в коде Netflix или YouTube. Но также не слышал, чтобы там использовался Oracle или бизнес-логика в хранимых процедурах.

А сам не пробовал своим умом думать? Попробуй - понравится.

Пробовал, и понимаю, что бизнес-логику в базе намного сложнее поддерживать, тестировать и изменять. Ещё сложнее становится понимать, как именно работает код, если его логика размазана по двум местам и написана в радикально отличающемя стиле.

Можно подумать, в разработке и без того легко, и код легко понимается всеми…

бизнес-логика в хранимых процедурах.

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

… Они и в бизнес-логике в базе тоже напишут какую-нибудь дичь…

Кто ж их туда пустит. :)

… Вряд ли есть хоть одно такое место в коде Netflix или YouTube. Но также не слышал, чтобы там использовался Oracle или бизнес-логика в хранимых процедурах.

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

А Oracle, вообще ни причём. (Сам это чудо видел хрен его знает сколько лет назад и то сбоку.)

… бизнес-логику в базе намного сложнее поддерживать, тестировать и изменять.

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

… логика размазана по двум местам и написана в радикально отличающемя стиле.

Ага, конечно, «два места»… Хорошо если не десяток… Вот и оставьте в одном - в базе.

… для остальных - действительно лучше сервер приложений.

Свои плюсы-минусы, но как вариант - вполне себе.

Бизнес логику можно с разными ухищрениями, соглашениями о наименованиях и т.д. делать в разных СУБД и не только в Oracle. Просто в Oracle c его PL/SQL пакетами бизнес-логика (и API, которые дергают приложения, генерирующий GUI) делается на порядок проще.

Microsoft предлагала сделать PL/SQL стандартом для СУБД, но Oracle высказался против.

Поэтому я и написал выше, а почему не прикрутить к СУБД - немного модифицированный ADA? В ADA и функционала больше чем в PL/SQL (который основан на ADA).

Хотя сейчас пошла тенденция прикручивать к СУБД Python и JavaScript, причем без «глубокой» интеграции с движком SQL СУБД.

И мне не нравятся скриптовые, безтиповые языки - на них быстро разрабатывать, но потом отлавливать кучу ошибок, что в случае с данными - недопустимо.

Кто ж их туда пустит. :)

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

«Вы - лохи, а я тут работаю в коллективе сеньёров-помидоров, выдающихся умов нашего века, бюджеты неограничены, сроки неограничены, Oracle можем купить любой версии, как и любое железо, хоть 10 дата-центров, хоть 1,000 мейнфреймов»

А по сути, все остальные вынуждены жить в условиях ограничений по всем параметрам. Людей на рынке труда нет. Бюджеты на людей ограничены. Бюджеты на софт ограничены. Бюджеты на железо ограничены. Сроки ограничены. Даже у Google и Netflix.

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

У них миллион различных проектов, и даже в самом YouTube, уверен, ACID во многих местах необходим.

Бизнес логику можно делать в разных СУБД и не только в Oracle.

Можно, но лучше не надо. Довелось поработать с этим хроническим ужосом.

… Довелось поработать с этим хроническим ужосом.

Да ладно, не всё так ужасно. :)

… «Вы - лохи, а я тут работаю в коллективе сеньёров-помидоров, выдающихся умов нашего века, бюджеты неограничены, сроки неограничены, Oracle можем купить любой версии, как и любое железо, хоть 10 дата-центров, хоть 1,000 мейнфреймов»

Простите, а из каких моих слов Вы сделали такой вывод?

… А по сути, все остальные вынуждены жить в условиях ограничений по всем параметрам. Людей на рынке труда нет. Бюджеты на людей ограничены. Бюджеты на софт ограничены. Бюджеты на железо ограничены. Сроки ограничены.

Дык, я и есть эти «остальные». По сути. :)

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

Можно поинтересоваться? «Серьезные приложения» - это какие? В Oracle с PL/SQL есть ворох проблем, которые не решаются ну вообще никак:

• есть «знаменитая» ошибка ORA-04061 (как пытаются решать написано, к примеру, здесь: https://stackoverflow.com/a/49390937/3426309), которая при обновлении кода заставляет выкинуть ошибку на клиента (т.е. в PL/SQL ее перехватить нельзя) - с этой ситуации я тихо офигеваю, потому что клиенты Oracle ежегодно отваливают тонны нефти, а оно как не позволяло делать обновления online, так и не позволяет.
• вендоры в основном разработчикам предоставляют нечто, похоже на ЯП, но далее за этим ЯП совершенно ничего не стоит, т.е. условно «вот вам синтаксис, вы на нем можете реализовать триггер или простенькую процедуру, а если хотите дальше - изобретайте свои велосипеды» - такое более-менее еще было приемлемо в 200х, а сейчас на такой подход (язык есть, среды нет) сразу выбрасывается красный флаг, как со стороны архитекторов, так и со стороны заказчиков (тупо идем на сайт вакансий и смотрим сможем ли мы свое чудо инженерной мысли поддерживать на плавы через пару лет) - ситуация в целом примерно такая же как с коболом: чемодан с ручкой есть, желающих его тащить уже нет.
• в языке даже не реализованы базовые концепции, которые сейчас де-факто являются стандартными, например, реализация полиморфизма на хранении кусков SQL-запросов в таблицах - это ничерта не полиморфизм.
• оно совершенно никак не масштабируется - код умеет разве что ходить в один экземпляр СУБД и на этом все, а в современных ИС доля трафика к СУБД от силы превышает 10-20%, т.е. люди, которые возьмут на себя ответственность (если еще убедят заказчика и архитектора) за реализацию бизнес-логики в СУБД, будут этакими мальчиками на побегушках, просто потому, что то что, что они делают, совершенно несущественно и вполне себе легко заменяется.

Если говорить про PL/pgSQL, то у него вместо первого пункта выступает другой: он тормозной, потому что не компилируется, в отличии от «конкурента».

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

Ради интереса загуглил мнения других:

https://softwareengineering.stackexchange.com/questions/158534/pros-and-cons-of-holding-all-the-business-logic-in-stored-procedures-in-web-appl

IMHO, общий консенсус, что в современном мире, это скорее антипаттерн.

Буду рад увидеть конкретные ссылки на доказательство обратного. Хотя бы какой-нибудь блог, где были бы минимальные объективные аргументы типа «мы перенесли бизнес-логику в СУБД, и у нас всё ускорилось, облегчилось, и заколосилось».

Пока что видны сотни тысяч аргументов об обратном.

есть «знаменитая» ошибка ORA-04061

Мдя….

Это «ошибка» только для ORM-пейсателей, а для разработчиков СУБД - это описанное в документации поведение, согласно внутренней логики работы PL/SQL в Oracle. И тонны нефти тут не при чем.

И никто сейчас, в эпоху ITIL/ITSM, в здравом уме не меняет на промышленном сервере СУБД с крупным бизнес-приложением логику «на лету». Для этого есть цикл: Разработка в Cреде разработка > Тестирование функциоанал аналитиками > Тестирование инсталляции админами > Комитет по внедрениям > Окно для установки на Промышленную среду > Установка > Отчет об установке или Откат установки в случае ошибок.

Менять «на горячую» пакеты и логику на работающей Промышленной среде могут как раз только безхозные любители ORM-ов.

вендоры в основном разработчикам предоставляют нечто, похоже на ЯП, но далее за этим ЯП совершенно ничего не стоит, т.е. условно «вот вам синтаксис, вы на нем можете реализовать триггер или простенькую процедуру, а если хотите дальше - изобретайте свои велосипеды»

Извините, но этот поток разума я не осилил. Поточнее не можете выразить свою мысль? Может мы вас поймем и даже чем-то поможем?

Но на всякий случай додумаю за вас: PL/SQL - это специализированный язык для работы с данными, хранящимися внутри СУБД. Для этого в нем в общем-то все есть. Что вам еще от него требуется? Моднявые Web-Фреймворки, писать игрушки-стрелялки, сетевые приложения или может еще чего?

Знаете ли - каждый инструмент, а PL/SQL - инструмент, предназначен для своей операции.

… ситуация в целом примерно такая же как с коболом: чемодан с ручкой есть, желающих его тащить уже нет…

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

… оно совершенно никак не масштабируется - код умеет разве что ходить в один экземпляр СУБД и на этом все…

Сложно спорить с очевидным, но этот код - часть этого экземпляра. А масштабируемость БД - тема очень нетривиальная.

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

Вот и добрались до главного. Ответственность лучше скинуть на… Да пофиг на кого, у нас-то всё нормально, данные лежат, не пылятся, берите и пользуйтесь.

Менять «на горячую» пакеты и логику на работающей Промышленной среде могут как раз только безхозные любители ORM-ов.

проблема в том, что у «любителей ORM» добавление колонки в таблицу не ставит колом все приложение, а вот в PL/SQL это действие гарантированно приводит к инвалидации и ORA-04061. Сказки про ITIL здесь не нужно рассказывать: PL/SQL самостоятельно в CI не умеет совершенно никак, поэтому имеем то что имеем: релизы нужно планировать на год вперед, потому что тупо нельзя добиться ситуации «тесты работают - значит приложение тоже работает» - здесь просто тесты написать невозможно.

Извините, но этот поток разума я не осилил.

ну то, что кто-то что-то не понял - это проблемы не мои. Ну ок, можно тему развить: как писать журнал выполнения *внокода на PL/SQL - что там из коробки есть? dbms_output? а для PostgreSQL? raise?

PL/SQL - это специализированный язык для работы с данными

поправлю: специализированный ненужный язык

… Ради интереса загуглил мнения других:

Вы мнения по этой ссылке вообще читали?

… Пока что видны сотни тысяч аргументов об обратном.

Простите, сколько? Их там ровно шесть если что.

Интересные мнения об обратном - «Субъективно быстрее», «Не можем осилить PL», «Мне проще писать на Java и С#».

в языке даже не реализованы базовые концепции, которые сейчас де-факто являются стандартными, например, реализация полиморфизма на хранении кусков SQL-запросов в таблицах - это ничерта не полиморфизм.

Карл, в PL/SQL нет полиморфизма? Серьезно, Карл? Я на этом Полиморфизме в PL/SQL для одной организации написал небольшую системку data quality.

Определение: Полиморфизм в языках программирования и теории типов — способность функции обрабатывать данные разных типов

Ну что-же, рассмотрим как это в PL/SQL

create or replace package plsqlpolimorf_pkg
as
  function add_two_fnc(p_param in number) return number;
  function add_two_fnc(p_param in string) return string;
end plsqlpolimorf_pkg;
/
create or replace package body plsqlpolimorf_pkg
as
  function add_two_fnc(p_param in number) return number is
  begin
    return (p_param + 2);
  end add_two_fnc; -- number
  function add_two_fnc(p_param in string) return string is
  begin
    return (to_char(to_number(p_param) + 2));
  end add_two_fnc; -- string
end plsqlpolimorf_pkg;
/
select
  plsqlpolimorf_pkg.add_two_fnc(2) as num_res,
  plsqlpolimorf_pkg.add_two_fnc('3') as string_res
from dual;

Или, Карл, дайте я обратно додумаю за вас - может, вы имели ввиду Динамический SQL?

Есть он в Oracle PL/SQL, и появился раньше чем в других СУБД, еще в том веке, сначала в виде пакета dbms_sql, а затем в виде оператора EXECUTE IMMEDIATE ‘SQL_CLAUSE’ и ничего ни в каких таблицах «куски SQL» хранить не надо, если я вас правильно понял, а то, может быть, у нас с вами разговор слепого с глухим…

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

Вы читали Дзен от создателя Pythona. Там есть одно хорошее правило - «Простое лучше Сложного». Я руководствуюсь им.

Если вы имели не то, о чем я написал - уточните.

Этот полиморфизм как раз Питонистам мешает. Чтоб дёргать процедурки с одинаковыми именами, но разными типами параметров - надо вручную типы указывать. Магия не работает - у питонистов депрессия.

Да и строго говоря не больно-то и надо. Проще всё-таки называть разными именами и не пытаться есть мозг бэкенду.

Этот полиморфизм как раз Питонистам мешает.

Я согласен, я выше уже написал своё мнение о нежелательности Python и JavaScript на стороне СУБД.

рассмотрим как это в PL/SQL

этого «полиморфизма» достаточно разве чтобы «Hello, World!» написать, предлагаю-таки пойти в бизнес-логику, за которую вы так радеете.

Это не мне. Я про автовакуум ничего не говорил.