Сравнение с точки зрения разработчика
Сразу оговорюсь — я ничего не имею против размещения части бизнес-логики в хранимых функциях, если это предусмотрено в архитектуре системы и оправдано рядом практических причин, выходящих за рамки данной статьи.
У меня давние и близкие отношения с Oracle. Я видел много отличных архитектур и кода, а также множество ужасных ошибок.
Oracle предоставляет разработчику неисчерпаемую пропасть возможностей, и почти всегда находится «хитрость», которая нужна именно сейчас.
В целом Oracle — потрясающий инструмент, и я не перестаю удивляться тому, как все это богатство может работать в принципе и надежно.
Около двух лет назад я перешел из мира Enterprise в свободное плавание, где махина Oracle с ее 47 тысячами долларов за ядро недосягаема.
Одним из первых внештатных проектов стал небольшой биллинговый сервис для субоператора спутниковой связи.
Встал вопрос о выборе СУБД.
От MySQL сразу отказались из-за неразвитости процедурного языка; выбор пал на PostgreSQL. Работая над этим и последующими проектами, я составил список субъективных плюсов и минусов PostgreSQL по сравнению с Oracle с точки зрения разработчика баз данных.
Представляю вашему вниманию:
PostgreSQL против Oracle
ПРО:
- Псевдотип серийный — сочетает в себе лучшие возможности auto_increment из MySQL и последовательности из Oracle.
- Вы можете писать функции на чистом SQL. .
Например, функция, состоящая из одного обновления c возвратом, возвращает идентификатор вновь добавленного значения.
Позволяет избавиться от явного объявления переменных, в которые выбираются данные и которые затем возвращаются взамен.
- Замечательно с в котором вы можете использовать не только выбор в качестве запроса, но также вставку, обновление, удаление возврата и который можно сделать рекурсивным (заменяет соединение Oracle).
Кроме того, он заменяет многотабличную вставку всех Oracle.
- Создать_серию вместо извращений типа выбора уровня из двойного подключения по уровню < n
- Очень мощный механизм контроля целостности данных, известный как ОГРАНИЧЕНИЯ — например, EXCLUDE позволяет делать хитрые проверки ДРУГИХ строк при вставке новой (иначе пришлось бы писать триггер), REFERENCES (внешний ключ) с действиями при удалении или изменении записей, на которые ссылается таблица.
Например, ограничение constname ссылается на tablename при каскадном удалении, что приведет к удалению связанных записей при удалении родительского элемента.
- Замечательная, но потенциально опасная (как и триггеры) система правил ( ПРАВИЛА ) позволяет заменить текст запроса, отправленного на сервер.
Через нее, например, реализован ПРОСМОТР .
- Удобный раздел ГДЕ в определении индекса позволяет уменьшить размер индекса, не прибегая к созданию функциональных индексов и нечитаемых условий, например, где decode(status,1,1,null)=1
- ПРЕДЕЛ со СМЕЩЕНИЕМ , позволяющий избежать геморроя с rownum, сортировкой и подзапросами.
- Приятная документация, лишенная сухости и чудовищности (но и дотошности) Oracle.
МИНУСЫ:
- Неприятные синтаксические анахронизмы, такие как необходимость выхода из тела ВЧ, например такой:
-
Большой Брат Билл: Опять 1984 Год!
19 Oct, 24 -
Фонд Бориса
19 Oct, 24 -
Быстро Создать Временный Проект
19 Oct, 24 -
Рунет Усманова?
19 Oct, 24 -
За Последний Год Количество Спама Удвоилось
19 Oct, 24
