Конечно, это зависит.
Это зависит от работы, которую выполняет конкретная хранимая процедура, и, возможно, не столько от «соотношения чтения / записи», которое вы предлагаете. В общем, вы должны рассмотреть возможность включения единицы работы в транзакцию, если это запрос, на который может повлиять какой-то другой, одновременно выполняющийся запрос. Если это звучит недетерминировано, это так. Зачастую сложно предсказать, при каких обстоятельствах конкретная единица работы считается кандидатом на это.
Хорошее место для начала - просмотреть точную CRUD , выполняемую в единице работы, в данном случае в рамках вашей хранимой процедуры, и решить, может ли она a) быть затронута какой-либо другой, одновременной операция и б) если эта другая работа имеет значение для конечного результата этой работы (или даже наоборот). Если ответ «Да» на оба вопроса, рассмотрите возможность упаковки единицы работы в транзакцию.
Это говорит о том, что вы не всегда можете просто решить либо использовать, либо не использовать транзакцию s, скорее вам следует применять их, когда это имеет смысл. Используйте свойства, определенные ACID (атомарность, согласованность, изоляция и долговечность), чтобы помочь решить, когда это может иметь место.
Еще одна вещь, которую следует учитывать, заключается в том, что в некоторых обстоятельствах, особенно если система должна выполнять много операций в быстрой последовательности, например, приложение обработки транзакций большого объема, вам может потребоваться взвесить относительные затраты производительности транзакции. В зависимости от размера единицы работы фиксация (или откат) транзакции может быть ресурсоемкой, возможно, негативно сказываясь на производительности вашей системы излишне или, по крайней мере, с ограниченной выгодой.
К сожалению, это не простой вопрос, чтобы точно ответить: «Это зависит».