Если вам нравится наш магазин - скажите об этом Google!
|
|
1 у.е. = 84.87 руб. |
|
Цены показывать: |
|
|
|
|
|
PostgreSQL vs Oracle
20.08.2012 13:03
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:
ЗаключениеХорошим дополнением этому списку было бы сравнение с точки зрения DBA, но тут, как говорится, я не вполне копенгаген. Было бы очень интересно в будущем увидеть такое сравнение на Хабре.Выводы? PostgreSQL есть куда расти, но уже сейчас при разработке проектов не сверхбольших масштабов он выглядит очень достойно рядом с чего уж таить - эталоном рынка РСУБД.
Ссылки по теме
|
|
|