Внезапно: транзакции в Postgresql
Dec. 27th, 2011 02:19 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassВот всю жизнь делаешь что-то, думаешь, что это очевидно, а потом берешь другую СУБД и оказывается, что там все сделано по другому.
Вот, например Postgresql vs Firebird:
1) В первом запросы отсылаются на сервер плейнтекстом, даже отпрепаренные с переменными. Во втором - сначала prepare, потом вызов полученного хендла с массивом параметров(бинарным) сколько надо раз. Впрочем, это может быть и особенность либы для доступа к Postgresql.
2) В первом транзакция одна на коннект, во втором - несколько на коннект.
3) В первом единственная ошибка в запросе в транзакции автоматом делает эту транзакцию невалидной целиком, и не дает ничего сделать до rollback. Во втором - транзакцию можно завершить, можно откатить, можно обработать ошибку и продолжить работать дальше. Не выполнится ровно один запрос. Чтобы имитировать такое в postgresql - нужно делать SAVEPOINT перед каждой query и откатываться на нее при ошибке.
Ну еще можно вспомнить про дотнет-драйвера обоих - в первом запрос-внутри-запроса выполнить невозможно, во втором свободно. Т.е. в postgresql "вычитать все шапки накладных, на каждую шапку вычитывая строки" - делается исключительно через жопие, методом "фетчим весь результат первого запроса, закрываем, затем выполняем второй сколько нужно раз".
Вот, например Postgresql vs Firebird:
1) В первом запросы отсылаются на сервер плейнтекстом, даже отпрепаренные с переменными. Во втором - сначала prepare, потом вызов полученного хендла с массивом параметров(бинарным) сколько надо раз. Впрочем, это может быть и особенность либы для доступа к Postgresql.
2) В первом транзакция одна на коннект, во втором - несколько на коннект.
3) В первом единственная ошибка в запросе в транзакции автоматом делает эту транзакцию невалидной целиком, и не дает ничего сделать до rollback. Во втором - транзакцию можно завершить, можно откатить, можно обработать ошибку и продолжить работать дальше. Не выполнится ровно один запрос. Чтобы имитировать такое в postgresql - нужно делать SAVEPOINT перед каждой query и откатываться на нее при ошибке.
Ну еще можно вспомнить про дотнет-драйвера обоих - в первом запрос-внутри-запроса выполнить невозможно, во втором свободно. Т.е. в postgresql "вычитать все шапки накладных, на каждую шапку вычитывая строки" - делается исключительно через жопие, методом "фетчим весь результат первого запроса, закрываем, затем выполняем второй сколько нужно раз".
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2011-12-27 12:18 pm (UTC)Фичей некоторых полезных нет - типа partitioning, репликации нормальной, итд итп. Из фич уровня языка разве что window functions не хватает, остальное весьма хорошо.
Со служебными средствами (человеческие логи, средства мониторинга, утилиты, текстовый бэкап) - печально, разработчики считают что это не нужно и занимаются больше внутренностями БД.
С документацией не очень хорошо. Комьюнити немного самоогороженное, нервничают когда про них пишут.
Очень удобна для мелких-средних проектов, с точки зрения программирования. Серверный код (императивное расширение sql) достаточно логично устроен, компонент доступа чуть более чем дохрена. Средств разработки под нее как бы не больше чем средств эксплуатации.
no subject
Date: 2011-12-27 12:45 pm (UTC)no subject
Date: 2011-12-29 01:54 am (UTC)Однако если сырцы триггеров и процедур из базы удалены - то конечно в таком случае текстовый бэкап не проканает.