Из Oracle да в Postgres

[eyeless_watcher]

date '2001-09-28' + (to_char(p_hours, '99') || ' hour')::interval

Интервалы можно умножать.

date '2001-09-28' + interval '1 hour' * p_hours

[GlukKazan]

Да, так тоже можно было сделать

[sparhawk]

Все процедуры и пакеты содержали в основном SQL, и больших объемов PL/SQL в проекте не было?

[GlukKazan]

В основном да. И переписывались не все пакеты а только необходимые.

[zBit]

Интересно ещё на сколько сложнее бы вам было переехать на MySQL, чем вы переехали на PG. Всё же PG больше похож на Oracle, чем MySQL. В PG даже PL/pgSQL есть, который создавался под вдохновением оракловской PL/SQL.

И для меня очень странно было читать вот это

в то время как MySQL заманивал производительностью и «нулевым» администрированием.

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

[GlukKazan]

Я тоже вынес из своей работы с MySQL мало приятных впечатлений. Другая шабашка была еще раньше. Особенно убило то что при изменении версии у меня сломалась большая часть SQL-запросов. Как раз перед показом. Точных версий уже не помню, давно было. Думаю, что переписывания под MySQL было бы более трудоемким.

[zBit]

Как мне кажется, если с MySQL на PG переехать не очень сложно, то с PG на MySQL переехать не всегда возможно. Это из-за того, что PG более гибкий и функциональный, чем MySQL. Но так было ещё в 2013 году, когда я последний раз взглянул на MySQL и забыл про него как про страшный сон. Хотя, Workbench там был очень хорош, жаль, что для PG нет такого мощного и бесплатного инструмента…

[wersoo]

Пока еще бесплатная IDE 0xDBE от JetBrains (или хотя бы плагин для IDEA) конечно не полная замена Workbench, но может значительно помочь в бытовых мелочах.

[zBit]

А мы пользуемся EMS SQL Manager for PostgreSQL Freeware. Бесплатной функциональности вполне хватает. Думаю, что платная версия может потягаться в Workbench'ем :)

[vazir]

Я както думал купить у них платную — (всетаки есть там полезные добавки, и баз у меня под сотню), но обнаружил что она не работает в wine (защита там не понимает (или не понимала, 5 лет как прошло) wine). Написал им письмецо — спросил что так и собираются ли исправить. Меня очень удивил ответ — "Мы не пробовали, но работает в платном Virtuozo эмуляторе". Ну и соответственно не купил ничего.

[DefineS]

а dbForge Studio for MySQL пробовали? хорошая тула

[vazir]

Я не использую MySQL — но вроде у них есть чтото и под постгрес. Погляжу, спасибо

[vazir]

Download dbForge Studio for PostgreSQL
Coming soon…

[DefineS]

Недавно была зарелижена свежая версия dbForge Studio for PostgreSQL 2.0 — blog.devart.com/whats-new-in-dbforge-studio-for-postgresql-20.html

[tgz]

В мускуле запрос может сломаться от изменения конфига, чего уж там версия сервера.

[igor_suhorukov]

Платная версия Postgresql поддерживает миграцию и с PL/SQL: PL/SQL Support

[GlukKazan]

Наверняка придется руками допиливать. За ссылку спасибо.

[asm0dey]

Ну, EnterpriseDB утверждает что полностью совместимо. Правда есть целая книга по различиям в реализации, говорят :)
Но вообще оно типа bug-to-bug compatible с оракловой реализацией.

[GlukKazan]

Надо будет посмотреть. Но вообще, в PostgreSQL нас больше всего интересует бесплатность.

[Aiki]

А вы не рассматривали вариант использовать ORM? Просто в таком случае можно было бы использовать практический любую СУБД, всего лишь поменяв конфиг.

[GlukKazan]

Здесь не я решал (кроме меня разработчиков хватает). В нашем продукте ORM не используется.
От себя добавлю, что не верю в чудодейственную силу ORM-ов в решении вопросов независимости от СУБД.
Особенно при наличии огромного количества платформозависимого кода.

[hell0w0rd]

Как ORM поможет с вьюшками, функциями? ORM это очень большой костыль, который обычно только тормозит разработку, приходится бороться с факапами конкретной ORM.
И судя по посту в проекте было подобие миграций, в виде xml описания схемы данных.

[GlukKazan]

Да, XML описания очень помогли. И помогают.

[VladVR]

ORM, к сожалению не обладают такой магией. Хотя если СУБД близки друг к другу, то может это и возможно. Переход же с MS SQL на Oracle или обратно практически невозможен без перекомпиляции. Только если изначально затачиваться на такую возможность. К примеру в MS SQL есть тип uniqueidentifier, а в Oracle для этой же цели приходится использовать CHAR(32 BYTE). C number тоже пляски, ODP.Net переводит один и тот же тип в любой их целых, decimal или double в зависимости от точности, в случае же MS есть отдельный тип на уровне БД.

Кстати насчет скорости работы — в Oracle неюзабелен Bulk Insert, поскольку не позволяет использовать ни триггеры, ни констрейнты, ни даже первичный ключ. Да еще и в транзакции он не работает. Вместо него приходится использовать т.н. array bind — операции, что работает несравнимо медленнее. В МS-же Bulk Insert это просто чудо. Еще Oracle очень медленно работает со строковыми типами. простой select из таблицы где есть varchar(4000) заставит его надолго задуматься, при этом в MSSQL это работает без сучка т.с. Т.е. даже если и возможно написать универсальный код, который просто будет работать на обеих СУБД, этого будет недостаточно, когда речь пойдет о производительности, запросы «летающие» на одной базе, будут нещадно тупить на другой и платформозависимый код писать придется в любом случае.

[alklim]

Вступлюсь слегка за MySQL.

Странно читать про низкую производительность.
У нас в проекте мы загружаем минутный лог, содержащий 4 млн. строк (файл 500 МБ) за 20 секунд используя LOAD DATA INFILE.
Уходит на это всего 20 секунд. Таким образом у нас производительность записи данных в MySQL составляет порядка 200 тыс строк в секунду.
Конечно, это просто загрузка лога, без какой-либо логики (IGNORE или UPDATE).
Дальнейшая логика обработки данных в MySQL тоже делается без труда — в нашем случае за счет быстрых MEMORY таблиц и правильного партицирования, которое распараллеливает задачу и ускоряет обработку в разы.

Критиковать и/или спорить про PG не собираюсь, ибо не знаю как. Все задачи, которые в проекте встречались, были успешно решены на MySQL, поэтому переезд на другую БД, например на PG, мы и не планировали.

[GlukKazan]

Я тоже прошу не воспринимать мой тест как критику. В той задаче были очень специфические требования по производительности.
Именно на этом тесте InnoDB показало одинаковые (чуть лучшие) результате с PG. MyISAM туда ставить было нельзя.

[le0pard]

Для PG можете взять pgloader.io/ — скорость может быть и выше (зависит от диска и настроек PostgreSQL).

[vazir]

В постгресе есть для этого случая COPY
— COPY — copy data between a file and a table
www.postgresql.org/docs/9.4/static/sql-copy.html

[ivanko]

+1 Унаследованная от PG Vertica этот самый COPY использует в хвост и в гриву. Фактически единственный способ заливки данных.

[hell0w0rd]

mysql очень ущербен по функционалу. Банально один раз попробовав функциональные индексы не понимаешь, как раньше без них жил. А еще куча типов, которые позволяют сделать фактически вообще все, что угодно.

[coh]

Это просто бизнес, ничего личного. www.nixp.ru/news/13138.html

[le0pard]

del

[BigD]

А с Ораклом итоговую производительность не сравнивали на том же железе?

[GlukKazan]

С производительностью все непросто. запросы слишком разнородные и наполнение для различных проектов тоже. Есть один проект который я не решусь переводить на PostgreSQL (и не надо на самом деле). Там 10-ки миллионов объектов. В том проекте который переводится на PostgreSQL данных на несколько порядков меньше.

[asm0dey]

А вы Ora2pg не пробовали? ПО идее должно было за вас решить большую часть проблем (ну может кроме рекурсивных запросов, не помню).

[GlukKazan]

Рекурсивные запросы и составили большую часть работы. Но не только в них дело. В Oracle есть вещи к которым мы просто привыкаем. Например к неявным преобразованиям типов или к тому что null и пустая строка — одно и то же. А в других СУБД это не так! Есть трюки для достижения лучшей производительности (например то, что индексы не содержат NULL-значения), которые тоже не работают. Всё это приходится очень вдумчиво переписывать.

[asm0dey]

Ну так кажется разумным сначала натравить на это дело ora2pg, а потом уже руками допиливать готовое по сути решение. Может оно и рекурсивные запросы умеет, кто знает?

[GlukKazan]

Возможно имеет смысл. В следующий раз попробую.

[zen]

Я бы тоже посоветовал использовать ora2pg, не забудем еще orafce. Насчет рекурсивных запросов я бы посоветовал обратиться к автору, вменяемый француз, быстро отвечает. Он у нас на конференции делал доклад pgconf.ru/static/presentations/2015/darold.pdf

[GlukKazan]

Да, так правильнее

[GlukKazan]

Если вы внимательно читали свои ссылки, то должны знать, что «в коробке» есть только возможность создания партиционированной таблицы. Перечитайте внимательно мою статью и поймёте, что я делаю ровно то же самое (за исключением добавления снапшотов). Что касается мат.представлений (снапшотов), в PostgreSQL они всё ещё не поддерживают инкрементальное обновление (по commit-у) агрегированных представлений. Моё решение его поддерживает.

[Angraver]

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

Вопрос исправили только в 9.4.

[ZOXEXIVO]

У Oracle есть Hard&Soft парсинг запросов с использованием глобального кэша.
Когда у вас тормозные отчеты или долгие операции — все равно что использовать.
При большом потоке запросов, которым нужна скорость у PostgreSQL будут ощутимые проблемы и просадки, если не использовать какие-то поделки.