(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

PostgreSQL vs Oracle

Источник: habrahabr
CPro

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




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

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

Ссылки по теме


 Распечатать »
 Правила публикации »
  Написать редактору 
 Рекомендовать » Дата публикации: 03.09.2012 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
Oracle Database Personal Edition Named User Plus Software Update License & Support
Oracle Database Standard Edition 2 Processor License
Oracle Database Standard Edition 2 Named User Plus License
Oracle Database Personal Edition Named User Plus License
SAP Crystal Reports XI R2 Dev 2006 INTL WIN NUL License (Version 11)
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Программирование на Microsoft Access
CASE-технологии
СУБД Oracle "с нуля"
Мир OLAP и Business Intelligence: новости, статьи, обзоры
3D и виртуальная реальность. Все о Macromedia Flash MX.
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
 



    
rambler's top100 Rambler's Top100