PostgreSQL vs Oracle

Сравнение с точки зрения разработчика

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

C Oracle у меня старые и тесные взаимоотношения. Видел много отличных архитектур и кода, и много ужасных «залеп». Oracle предоставляет разработчику неисчерпаемую бездну возможностей, и практически всегда находится нужная именно сейчас «фишка».
В целом, Oracle — удивительный инструмент, и я не устаю удивляться тому, как всё это богатство может работать в принципе и работать стабильно.

Около двух лет назад я перешёл из Enterprise мира в свободное плавание, где махина Oracle с её $47k за ядро — вне досягаемости.
Одним из первых freelance проектов был небольшой биллинг для суб-оператора спутниковой связи. Встал вопрос выбора РСУБД. MySQL сразу отпал по причине недоразвитости процедурного языка, выбор пал на PostgreSQL.

По мере работы над этим и следующими проектами я составлял список субъективных плюсов и минусов PostgreSQL по сравнению с Oracle с точки зрения разработчика БД. Его и представляю вашему вниманию:

PostgreSQL vs Oracle

PRO:

• Псевдо тип serial — объединяет лучшие черты auto_increment из MySQL и sequence из Oracle.
• Можно писать функции на чистом SQL. Например функция, состоящая из одного update c returning, возвращающая идентификатор только что добавленного значения. Позволяет избавится от явного объявления переменных, в которые выбираются данные и которые затем возвращаются в return.
• Замечательный with в котором можно в качестве запроса использовать не только select, но и insert, update, delete returning и который можно делать рекурсивным (заменяет оракловский connect by). Кроме того заменяет собой оракловский мультитабличный insert all.
• Generate_series вместо извращений типа select level from dual connect by level < n
• Очень мощный механизм контроля целостности данных aka CONSTRAINTS — например EXCLUDE позволяет делать хитрые проверки ДРУГИХ строк при вставке новой (иначе пришлось бы писать триггер), REFERENCES (foreign key) c действиями при удалении или изменении записей, на которые ссылается таблица. Например constraint constname references tablename on delete cascade удалит связанные записи при удалении родительской.
• Замечательная, но потенциально опасная (как триггеры) система правил (RULES) позволяющая подменять текст запроса отправляемый серверу. Через неё, например, реализованы VIEW.
• Удобный раздел WHERE в определении индекса, позволяет уменьшить размер индекса не прибегая к созданию функциональных индексов и нечитабельных условий типа where decode(status,1,1,null)=1
• LIMIT с OFFSET, позволяющие избежать геморроя с rownum, сортировкой и подзапросами.
• Приятная документация, лишённая сухости и монструозности (но и дотошности) оракловской.

CONS:

• Неприятные синтаксические анахронизмы, вроде необходимости ескейпить тело ХФ, например так:

  	function test() returns void as
  	$$
  	begin
  	end;
  	$$ language plpgsql;
         

  Или необходимость писать perform, чтобы вызвать процедуру по имени:
  perform my_proc(); вместо просто my_proc();

• Убогое партиционирование через наследование таблиц и триггеры (или правила).
• Нет механизма джобов на стороне сервера, все процессы должны быть инициированы снаружи базы (например, cron).
• Нет packages для хранимых функций. Приходится использовать для группировки схемы, но это не совсем то.
• Нет прекрасного хинта +parallel (выполнение запроса в несколько параллельных процессов) для ETL и прочих DWH-специфичных запросов. И вообще с многопоточностью туговато — для параллельных потоков приходится делать отдельный коннект к базе.
• Нет MERGE.
• Нет управления транзакциями в хранимых функциях. Может быть контроль транзакций снаружи это и более правильный подход, но мне не хватает возможности сделать явный commit или rollback прямо в ХФ.
• Можно без ошибок скомпилить ХФ, явно ссылающуюся на несуществующие объекты. Например с выборкой из несуществующей таблицы. Об ошибке узнаем только когда выполнится этот кусок ХФ, а не на этапе компиляции, как в Oracle.

Заключение

Хорошим дополнением этому списку было бы сравнение с точки зрения DBA, но тут, как говорится, я не вполне копенгаген. Было бы очень интересно в будущем увидеть такое сравнение на Хабре.

Выводы? PostgreSQL есть куда расти, но уже сейчас при разработке проектов не сверхбольших масштабов он выглядит очень достойно рядом с чего уж таить — эталоном рынка РСУБД.

Автор: CPro