Комментарии 45
date '2001-09-28' + (to_char(p_hours, '99') || ' hour')::interval
Интервалы можно умножать.
date '2001-09-28' + interval '1 hour' * p_hours
Все процедуры и пакеты содержали в основном SQL, и больших объемов PL/SQL в проекте не было?
Интересно ещё на сколько сложнее бы вам было переехать на MySQL, чем вы переехали на PG. Всё же PG больше похож на Oracle, чем MySQL. В PG даже PL/pgSQL есть, который создавался под вдохновением оракловской PL/SQL.
И для меня очень странно было читать вот это
И для меня очень странно было читать вот это
в то время как MySQL заманивал производительностью и «нулевым» администрированием.Когда я работал с MySQL и начал переходить на PG, то не заметил ни одного случая, когда MySQL был хоть чем-то лучше, чем PG.
Я тоже вынес из своей работы с MySQL мало приятных впечатлений. Другая шабашка была еще раньше. Особенно убило то что при изменении версии у меня сломалась большая часть SQL-запросов. Как раз перед показом. Точных версий уже не помню, давно было. Думаю, что переписывания под MySQL было бы более трудоемким.
Как мне кажется, если с MySQL на PG переехать не очень сложно, то с PG на MySQL переехать не всегда возможно. Это из-за того, что PG более гибкий и функциональный, чем MySQL. Но так было ещё в 2013 году, когда я последний раз взглянул на MySQL и забыл про него как про страшный сон. Хотя, Workbench там был очень хорош, жаль, что для PG нет такого мощного и бесплатного инструмента…
А мы пользуемся EMS SQL Manager for PostgreSQL Freeware. Бесплатной функциональности вполне хватает. Думаю, что платная версия может потягаться в Workbench'ем :)
Я както думал купить у них платную — (всетаки есть там полезные добавки, и баз у меня под сотню), но обнаружил что она не работает в wine (защита там не понимает (или не понимала, 5 лет как прошло) wine). Написал им письмецо — спросил что так и собираются ли исправить. Меня очень удивил ответ — "Мы не пробовали, но работает в платном Virtuozo эмуляторе". Ну и соответственно не купил ничего.
а dbForge Studio for MySQL пробовали? хорошая тула
Я не использую MySQL — но вроде у них есть чтото и под постгрес. Погляжу, спасибо
Download dbForge Studio for PostgreSQL
Coming soon…
Coming soon…
Недавно была зарелижена свежая версия dbForge Studio for PostgreSQL 2.0 — blog.devart.com/whats-new-in-dbforge-studio-for-postgresql-20.html
В мускуле запрос может сломаться от изменения конфига, чего уж там версия сервера.
Платная версия Postgresql поддерживает миграцию и с PL/SQL: PL/SQL Support
А вы не рассматривали вариант использовать ORM? Просто в таком случае можно было бы использовать практический любую СУБД, всего лишь поменяв конфиг.
Здесь не я решал (кроме меня разработчиков хватает). В нашем продукте ORM не используется.
От себя добавлю, что не верю в чудодейственную силу ORM-ов в решении вопросов независимости от СУБД.
Особенно при наличии огромного количества платформозависимого кода.
От себя добавлю, что не верю в чудодейственную силу ORM-ов в решении вопросов независимости от СУБД.
Особенно при наличии огромного количества платформозависимого кода.
Как ORM поможет с вьюшками, функциями? ORM это очень большой костыль, который обычно только тормозит разработку, приходится бороться с факапами конкретной ORM.
И судя по посту в проекте было подобие миграций, в виде xml описания схемы данных.
И судя по посту в проекте было подобие миграций, в виде xml описания схемы данных.
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 это работает без сучка т.с. Т.е. даже если и возможно написать универсальный код, который просто будет работать на обеих СУБД, этого будет недостаточно, когда речь пойдет о производительности, запросы «летающие» на одной базе, будут нещадно тупить на другой и платформозависимый код писать придется в любом случае.
Кстати насчет скорости работы — в Oracle неюзабелен Bulk Insert, поскольку не позволяет использовать ни триггеры, ни констрейнты, ни даже первичный ключ. Да еще и в транзакции он не работает. Вместо него приходится использовать т.н. array bind — операции, что работает несравнимо медленнее. В МS-же Bulk Insert это просто чудо. Еще Oracle очень медленно работает со строковыми типами. простой select из таблицы где есть varchar(4000) заставит его надолго задуматься, при этом в MSSQL это работает без сучка т.с. Т.е. даже если и возможно написать универсальный код, который просто будет работать на обеих СУБД, этого будет недостаточно, когда речь пойдет о производительности, запросы «летающие» на одной базе, будут нещадно тупить на другой и платформозависимый код писать придется в любом случае.
Вступлюсь слегка за MySQL.
Странно читать про низкую производительность.
У нас в проекте мы загружаем минутный лог, содержащий 4 млн. строк (файл 500 МБ) за 20 секунд используя LOAD DATA INFILE.
Уходит на это всего 20 секунд. Таким образом у нас производительность записи данных в MySQL составляет порядка 200 тыс строк в секунду.
Конечно, это просто загрузка лога, без какой-либо логики (IGNORE или UPDATE).
Дальнейшая логика обработки данных в MySQL тоже делается без труда — в нашем случае за счет быстрых MEMORY таблиц и правильного партицирования, которое распараллеливает задачу и ускоряет обработку в разы.
Критиковать и/или спорить про PG не собираюсь, ибо не знаю как. Все задачи, которые в проекте встречались, были успешно решены на MySQL, поэтому переезд на другую БД, например на PG, мы и не планировали.
Странно читать про низкую производительность.
У нас в проекте мы загружаем минутный лог, содержащий 4 млн. строк (файл 500 МБ) за 20 секунд используя LOAD DATA INFILE.
Уходит на это всего 20 секунд. Таким образом у нас производительность записи данных в MySQL составляет порядка 200 тыс строк в секунду.
Конечно, это просто загрузка лога, без какой-либо логики (IGNORE или UPDATE).
Дальнейшая логика обработки данных в MySQL тоже делается без труда — в нашем случае за счет быстрых MEMORY таблиц и правильного партицирования, которое распараллеливает задачу и ускоряет обработку в разы.
Критиковать и/или спорить про PG не собираюсь, ибо не знаю как. Все задачи, которые в проекте встречались, были успешно решены на MySQL, поэтому переезд на другую БД, например на PG, мы и не планировали.
Я тоже прошу не воспринимать мой тест как критику. В той задаче были очень специфические требования по производительности.
Именно на этом тесте InnoDB показало одинаковые (чуть лучшие) результате с PG. MyISAM туда ставить было нельзя.
Именно на этом тесте InnoDB показало одинаковые (чуть лучшие) результате с PG. MyISAM туда ставить было нельзя.
Для PG можете взять pgloader.io/ — скорость может быть и выше (зависит от диска и настроек PostgreSQL).
В постгресе есть для этого случая COPY
— COPY — copy data between a file and a table
www.postgresql.org/docs/9.4/static/sql-copy.html
— COPY — copy data between a file and a table
www.postgresql.org/docs/9.4/static/sql-copy.html
mysql очень ущербен по функционалу. Банально один раз попробовав функциональные индексы не понимаешь, как раньше без них жил. А еще куча типов, которые позволяют сделать фактически вообще все, что угодно.
Это просто бизнес, ничего личного. www.nixp.ru/news/13138.html
del
А с Ораклом итоговую производительность не сравнивали на том же железе?
С производительностью все непросто. запросы слишком разнородные и наполнение для различных проектов тоже. Есть один проект который я не решусь переводить на PostgreSQL (и не надо на самом деле). Там 10-ки миллионов объектов. В том проекте который переводится на PostgreSQL данных на несколько порядков меньше.
А вы Ora2pg не пробовали? ПО идее должно было за вас решить большую часть проблем (ну может кроме рекурсивных запросов, не помню).
Рекурсивные запросы и составили большую часть работы. Но не только в них дело. В Oracle есть вещи к которым мы просто привыкаем. Например к неявным преобразованиям типов или к тому что null и пустая строка — одно и то же. А в других СУБД это не так! Есть трюки для достижения лучшей производительности (например то, что индексы не содержат NULL-значения), которые тоже не работают. Всё это приходится очень вдумчиво переписывать.
Ну так кажется разумным сначала натравить на это дело ora2pg, а потом уже руками допиливать готовое по сути решение. Может оно и рекурсивные запросы умеет, кто знает?
Возможно имеет смысл. В следующий раз попробую.
Я бы тоже посоветовал использовать ora2pg, не забудем еще orafce. Насчет рекурсивных запросов я бы посоветовал обратиться к автору, вменяемый француз, быстро отвечает. Он у нас на конференции делал доклад pgconf.ru/static/presentations/2015/darold.pdf
Если вы внимательно читали свои ссылки, то должны знать, что «в коробке» есть только возможность создания партиционированной таблицы. Перечитайте внимательно мою статью и поймёте, что я делаю ровно то же самое (за исключением добавления снапшотов). Что касается мат.представлений (снапшотов), в PostgreSQL они всё ещё не поддерживают инкрементальное обновление (по commit-у) агрегированных представлений. Моё решение его поддерживает.
Материальными представлениями в 9.3 лучше не пользоваться: их обновление блокирует наглухо все таблицы, связанные в представлении. Табличной блокировкой, обращаю на это специальное внимание.
Вопрос исправили только в 9.4.
Вопрос исправили только в 9.4.
У Oracle есть Hard&Soft парсинг запросов с использованием глобального кэша.
Когда у вас тормозные отчеты или долгие операции — все равно что использовать.
При большом потоке запросов, которым нужна скорость у PostgreSQL будут ощутимые проблемы и просадки, если не использовать какие-то поделки.
Когда у вас тормозные отчеты или долгие операции — все равно что использовать.
При большом потоке запросов, которым нужна скорость у PostgreSQL будут ощутимые проблемы и просадки, если не использовать какие-то поделки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Из Oracle да в Postgres