Должен ли я использовать свои транзакции на уровне хранимых процедур или на уровне среднего уровня?

Question

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

Другой вариант в нашем ORM - это создание пользовательских хранимых процедур, которые он просто вызывает.Мне было интересно - было бы быстрее, если бы я просто создал пользовательскую хранимую процедуру с транзакцией SQL вместо нее?

Разве это не было бы намного быстрее?Если так, почему большинство людей выбирают маршрут ORM?Я имею в виду, что появление объектов вашей базы данных в объектной модели делает вещи действительно простыми, как это выглядит в intellisense, но является ли это единственной причиной, по которой вы отказались бы от производительности для простоты использования?

Answer 1

Хранимые процедуры дают вам дополнительные преимущества в производительности благодаря оптимизации, которую программное обеспечение БД может выполнять с известным запросом.Когда вы используете специальные запросы, вы теряете это преимущество.

Я не знаю вашей конкретной системы, поэтому я не уверен, что подходит именно вам.Для нас мы обнаружили, что добавление столько логики, сколько имело смысл в хранимые процессы на уровне БД, позволило нам создать слой бизнес-логики, используя Views и Stored procs.Это значительно упростило процесс кодирования, и данные всегда обрабатывались единообразно.

Answer 2

Мне кажется, что бизнес-транзакция и транзакция базы данных должны обрабатываться независимо. Я использую БД для выполнения CRUDS и применяю управление транзакциями к этим конкретным функциям по мере необходимости. На среднем уровне вы также можете применять управление транзакциями, но в бизнес-сценариях и обрабатывать ошибки, возникающие в базе данных, для управления потоком.

Например, если в базе данных произошел сбой вставки, выдается ошибка и обрабатывается на среднем уровне. Оттуда он может перехватить исключение БД и выполнить надлежащие шаги для отката других объектов.

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