oracle-postgresql

Les
Дата: 05.10.2015 14:38:34
Добрый день!
Руководство хочет посмотреть на постгрю, поэтому прошу совета и мнения.
Сейчас у нас на Oracle 11.2 вся основная бизнес логика лежит в хранимке в базе, по пакетам,
клиент на джаве, данные отдаются через объектные таблицы.

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

Заранее спасибо
там хорошо, где рабы не мы
Дата: 05.10.2015 14:46:17
Les,

цель опроса мигрантов в исходном форуме? кто эммигрировал, тот там и сидит...
roadster
Дата: 05.10.2015 14:51:19
там хорошо, где рабы не мы
Les,

цель опроса мигрантов в исходном форуме? кто эммигрировал, тот там и сидит...
+1
но добавлю, что слышал о том, что PL/SQL код ложится ровно, а вот с SQL придётся разобраться.
tru55
Дата: 05.10.2015 15:19:29
Вообще-то здесь есть форум Сравнение СУБД
Rinka777
Дата: 05.10.2015 16:28:07
roadster
там хорошо, где рабы не мы
Les,

цель опроса мигрантов в исходном форуме? кто эммигрировал, тот там и сидит...
+1
но добавлю, что слышал о том, что PL/SQL код ложится ровно, а вот с SQL придётся разобраться.


не может быть.
Alexander Ryndin
Дата: 05.10.2015 17:10:39
Rinka777
roadster
пропущено...
+1
но добавлю, что слышал о том, что PL/SQL код ложится ровно, а вот с SQL придётся разобраться.


не может быть.
+1. Это просто принципиально не может быть, потому как у PgSQL нет достаточно ресурсов, чтобы переписывать пакеты.
слегка наоборот
Дата: 05.10.2015 17:59:15
Rinka777
roadster
слышал о том, что PL/SQL код ложится ровно, а вот с SQL придётся разобраться.
не может быть.
не может быть, что он слышал?

Для начала, надо определиться, что есть plsql (plpgsql). Рассматривать его в отрыве от sql несколько странно, то есть переводить-то хранимки придется вместе с sql. То есть, чтобы plsql лег ровно, нужно, чтобы sql вообще лежал ровнее некуда.
Но даже в отрыве... Начнем с того, что в pg нет процедур! В plpgsql нет управления транзакциями (commit, rollback, автономки). Из курсорных атрибутов доступен только безымянный FOUND. Пакеты? С точки зрения именования их отсутствие эмулируется размещением в отдельной схеме, но пакетных переменных от этого не появляется. Приведение типов в большинстве случаев требует явной конверсии, с одной стороны компилятор скажет о проблемах, с другой, при многообразии числовых типов, можно получить тихие неожиданности с целочисленным делением. NULL и пустая строка различны - вычищать все ||-конкатенации в коде с обрамлением nullable-аргументов coalesce(..., '') или заменой на concat.
Коллизия имен между переменными plpgsql и sql по умолчанию приводит к ошибке, это замечательно, но тело хранимки в ddl это строка(!), и просто так имя хранимки ничего не значит внутри этой строки (хотя передачу параметров по имени все же сделали), чтобы сослаться в запросе на ИмяФункции.Переменная нужно добавить к блоку метку <<ИмяФункции>>. Проверки зависмостей от объектов при компиляции нет, так что не экономьте на тестировании редкопроходимых ветвей, даже простых exception when ... Кстати, логику работы с ними тоже придется пересмотреть из-за различий в исключениях. К тому же, по умолчанию select into не рейзит исключений, что строк нет или их больше одной.
Еще особенность строково-литеральности тела функции - заголовок не хранится как его указали при создании. То есть реверс-ddl потеряет комментарии промеж параметров, форматирование и даже типы и выражения для default будут переписаны на эквиваленты по усмотрению клиентского инструмента. Последнее замечание, это уже к дисциплине процесса разработки...
Таких мелочей тонны. Ах да, нет поддержики вложенных функций и обсуждать на форуме это - оскорбление чувств верующих.
kva6513
Дата: 05.10.2015 18:07:13
Alexander Ryndin
Это просто принципиально не может быть


Справедливости для - может. Я даже видел такой "код" своими глазами. Для каждого INSERT/UPDATE/DELETE написана отдельная "обертка" в виде функции на PL/SQL, принимающая параметры и ключи поиска и добросовестно перекладывающая все это в соответствующую команду SQL.
Понятно, что никакого реального программирования на PL/SQL там нет, все что есть, легко укладывается в возможности ANSI SQL, но тем не менее - номинально PL/SQL присутствует и, да, такой "код" можно "перенести гладко"... :)

PS: Описанное было представлено под гордым названием "API для работы с данными"...
Les
Дата: 05.10.2015 18:08:06
слегка наоборот,

Большое спасибо за ответ и приведенный список проблем
Victor Metelitsa
Дата: 05.10.2015 18:46:42
Les,

если вас интересует
* уход с платного на бесплатное,
* нагрузка на СУБД невелика,
* но Oracle XE таки слишком ограничивает
то есть ещё и такой вариант:
http://www.ibm.com/developerworks/data/library/techarticle/dm-0907oracleappsondb2/index.html
http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.apdv.plsql.doc/doc/c0053607.html?lang=en

ограничения бесплатной версии - 2 процессорных ядра, 16 гиг ОЗУ, 15 терабайтов данных.

Поддержка PL/SQL более или менее приличная. Хотя куча ограничений, куча отсутствующих (по сравнению с обычным набором) пакетов. И не очень быстрый, если переносить как есть. (Хотя, если попереписывать на DB2-шный синтаксис в виде inline-функций, наоборот, обгоняет ораклячьи эквиваленты). Тем не менее это много больше, чем предлагает Postgres в стандартной поставке.