Pull to refresh

PostgreSQL vs Oracle

Reading time 3 min
Views 62K

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




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

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 есть куда расти, но уже сейчас при разработке проектов не сверхбольших масштабов он выглядит очень достойно рядом с чего уж таить — эталоном рынка РСУБД.
Tags:
Hubs:
+66
Comments 201
Comments Comments 201

Articles