How to become an author
Search
Write a publication
Pull to refresh

Comments 45

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

Интервалы можно умножать.
date '2001-09-28' + interval '1 hour' * p_hours
Total votes 11: ↑11 and ↓0+11
Да, так тоже можно было сделать
This comment wasn’t rated yet0
Все процедуры и пакеты содержали в основном SQL, и больших объемов PL/SQL в проекте не было?
Total votes 2: ↑2 and ↓0+2
В основном да. И переписывались не все пакеты а только необходимые.
This comment wasn’t rated yet0
Интересно ещё на сколько сложнее бы вам было переехать на MySQL, чем вы переехали на PG. Всё же PG больше похож на Oracle, чем MySQL. В PG даже PL/pgSQL есть, который создавался под вдохновением оракловской PL/SQL.

И для меня очень странно было читать вот это
в то время как MySQL заманивал производительностью и «нулевым» администрированием.
Когда я работал с MySQL и начал переходить на PG, то не заметил ни одного случая, когда MySQL был хоть чем-то лучше, чем PG.
Total votes 9: ↑8 and ↓1+7
Я тоже вынес из своей работы с MySQL мало приятных впечатлений. Другая шабашка была еще раньше. Особенно убило то что при изменении версии у меня сломалась большая часть SQL-запросов. Как раз перед показом. Точных версий уже не помню, давно было. Думаю, что переписывания под MySQL было бы более трудоемким.
Total votes 5: ↑4 and ↓1+3
Как мне кажется, если с MySQL на PG переехать не очень сложно, то с PG на MySQL переехать не всегда возможно. Это из-за того, что PG более гибкий и функциональный, чем MySQL. Но так было ещё в 2013 году, когда я последний раз взглянул на MySQL и забыл про него как про страшный сон. Хотя, Workbench там был очень хорош, жаль, что для PG нет такого мощного и бесплатного инструмента…
Total votes 4: ↑4 and ↓0+4
Пока еще бесплатная IDE 0xDBE от JetBrains (или хотя бы плагин для IDEA) конечно не полная замена Workbench, но может значительно помочь в бытовых мелочах.
This comment wasn’t rated yet0
А мы пользуемся EMS SQL Manager for PostgreSQL Freeware. Бесплатной функциональности вполне хватает. Думаю, что платная версия может потягаться в Workbench'ем :)
This comment wasn’t rated yet0
Я както думал купить у них платную — (всетаки есть там полезные добавки, и баз у меня под сотню), но обнаружил что она не работает в wine (защита там не понимает (или не понимала, 5 лет как прошло) wine). Написал им письмецо — спросил что так и собираются ли исправить. Меня очень удивил ответ — "Мы не пробовали, но работает в платном Virtuozo эмуляторе". Ну и соответственно не купил ничего.
Total votes 1: ↑1 and ↓0+1
Я не использую MySQL — но вроде у них есть чтото и под постгрес. Погляжу, спасибо
This comment wasn’t rated yet0
Download dbForge Studio for PostgreSQL
Coming soon…
This comment wasn’t rated yet0
В мускуле запрос может сломаться от изменения конфига, чего уж там версия сервера.
Total votes 3: ↑2 and ↓1+1
Наверняка придется руками допиливать. За ссылку спасибо.
This comment wasn’t rated yet0
Ну, EnterpriseDB утверждает что полностью совместимо. Правда есть целая книга по различиям в реализации, говорят :)
Но вообще оно типа bug-to-bug compatible с оракловой реализацией.
Total votes 1: ↑1 and ↓0+1
Надо будет посмотреть. Но вообще, в PostgreSQL нас больше всего интересует бесплатность.
Total votes 1: ↑1 and ↓0+1
А вы не рассматривали вариант использовать ORM? Просто в таком случае можно было бы использовать практический любую СУБД, всего лишь поменяв конфиг.
Total votes 4: ↑2 and ↓20
Здесь не я решал (кроме меня разработчиков хватает). В нашем продукте ORM не используется.
От себя добавлю, что не верю в чудодейственную силу ORM-ов в решении вопросов независимости от СУБД.
Особенно при наличии огромного количества платформозависимого кода.
Total votes 13: ↑13 and ↓0+13
Как ORM поможет с вьюшками, функциями? ORM это очень большой костыль, который обычно только тормозит разработку, приходится бороться с факапами конкретной ORM.
И судя по посту в проекте было подобие миграций, в виде xml описания схемы данных.
Total votes 8: ↑8 and ↓0+8
Да, XML описания очень помогли. И помогают.
This comment wasn’t rated yet0
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 это работает без сучка т.с. Т.е. даже если и возможно написать универсальный код, который просто будет работать на обеих СУБД, этого будет недостаточно, когда речь пойдет о производительности, запросы «летающие» на одной базе, будут нещадно тупить на другой и платформозависимый код писать придется в любом случае.
Total votes 2: ↑2 and ↓0+2
Вступлюсь слегка за MySQL.

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

Критиковать и/или спорить про PG не собираюсь, ибо не знаю как. Все задачи, которые в проекте встречались, были успешно решены на MySQL, поэтому переезд на другую БД, например на PG, мы и не планировали.
Total votes 6: ↑4 and ↓2+2
Я тоже прошу не воспринимать мой тест как критику. В той задаче были очень специфические требования по производительности.
Именно на этом тесте InnoDB показало одинаковые (чуть лучшие) результате с PG. MyISAM туда ставить было нельзя.
Total votes 4: ↑3 and ↓1+2
Для PG можете взять pgloader.io/ — скорость может быть и выше (зависит от диска и настроек PostgreSQL).
Total votes 5: ↑4 and ↓1+3
+1 Унаследованная от PG Vertica этот самый COPY использует в хвост и в гриву. Фактически единственный способ заливки данных.
Total votes 2: ↑2 and ↓0+2
mysql очень ущербен по функционалу. Банально один раз попробовав функциональные индексы не понимаешь, как раньше без них жил. А еще куча типов, которые позволяют сделать фактически вообще все, что угодно.
Total votes 10: ↑9 and ↓1+8
А с Ораклом итоговую производительность не сравнивали на том же железе?
Total votes 2: ↑2 and ↓0+2
С производительностью все непросто. запросы слишком разнородные и наполнение для различных проектов тоже. Есть один проект который я не решусь переводить на PostgreSQL (и не надо на самом деле). Там 10-ки миллионов объектов. В том проекте который переводится на PostgreSQL данных на несколько порядков меньше.
This comment wasn’t rated yet0
А вы Ora2pg не пробовали? ПО идее должно было за вас решить большую часть проблем (ну может кроме рекурсивных запросов, не помню).
Total votes 2: ↑2 and ↓0+2
Рекурсивные запросы и составили большую часть работы. Но не только в них дело. В Oracle есть вещи к которым мы просто привыкаем. Например к неявным преобразованиям типов или к тому что null и пустая строка — одно и то же. А в других СУБД это не так! Есть трюки для достижения лучшей производительности (например то, что индексы не содержат NULL-значения), которые тоже не работают. Всё это приходится очень вдумчиво переписывать.
This comment wasn’t rated yet0
Ну так кажется разумным сначала натравить на это дело ora2pg, а потом уже руками допиливать готовое по сути решение. Может оно и рекурсивные запросы умеет, кто знает?
Total votes 1: ↑1 and ↓0+1
Возможно имеет смысл. В следующий раз попробую.
This comment wasn’t rated yet0
Я бы тоже посоветовал использовать ora2pg, не забудем еще orafce. Насчет рекурсивных запросов я бы посоветовал обратиться к автору, вменяемый француз, быстро отвечает. Он у нас на конференции делал доклад pgconf.ru/static/presentations/2015/darold.pdf
Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
UFO just landed and posted this here
Если вы внимательно читали свои ссылки, то должны знать, что «в коробке» есть только возможность создания партиционированной таблицы. Перечитайте внимательно мою статью и поймёте, что я делаю ровно то же самое (за исключением добавления снапшотов). Что касается мат.представлений (снапшотов), в PostgreSQL они всё ещё не поддерживают инкрементальное обновление (по commit-у) агрегированных представлений. Моё решение его поддерживает.
This comment wasn’t rated yet0
Материальными представлениями в 9.3 лучше не пользоваться: их обновление блокирует наглухо все таблицы, связанные в представлении. Табличной блокировкой, обращаю на это специальное внимание.

Вопрос исправили только в 9.4.
This comment wasn’t rated yet0
У Oracle есть Hard&Soft парсинг запросов с использованием глобального кэша.
Когда у вас тормозные отчеты или долгие операции — все равно что использовать.
При большом потоке запросов, которым нужна скорость у PostgreSQL будут ощутимые проблемы и просадки, если не использовать какие-то поделки.
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time
Unlock dark mode

Your account

Sections

Information

Services

Support
© 2006–2024, Habr