Целесообразно ли вызывать исключения в хранимых процедурах, охватывающих операции CRUD, когда затрагивается число строк! = 1?

Question

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

Я обертываю все свои операции UPDATE, DELETE, INSERT в хранимых процедурах и даю EXECUTE для моего пакета и SELECT для моих таблиц моему приложению. Для процедур UPDATE и DELETE у меня есть оператор IF в конце, в котором я делаю следующее:

IF SQL%ROWCOUNT <> 1 THEN
  RAISE_APPLICATION_ERROR(-20001, 'Invalid number of rows affected: ' || SQL%ROWCOUNT);
END IF;

Эту проверку также можно выполнить в коде приложения, поскольку число задействованных строк обычно доступно после выполнения оператора SQL.

Значит, я что-то упускаю или это не самый безопасный способ убедиться, что вы обновляете или удаляете именно то, что хотите, не больше, не меньше?

Answer 1

Я думаю, что это хороший путь.Если ожидается, что процесс pl/sql всегда будет обновлять / удалять / вставлять строку, и в противном случае это считается ошибкой, то в каком месте лучше поставить эту проверку, чем в самом процессе pl/sql?Таким образом, независимо от того, какой код на стороне клиента (C #, JAVA, PHP, Rails и т. Д.) Использует этот процесс, у вас есть централизованная проверка ошибок в одном месте.

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

Answer 2

В большинстве случаев я бы использовал ORM, такой как Hibernate, который выполняет аналогичные действия для обработки оптимистической блокировки.Также он будет использовать PK в предложении where.

Так что я бы посчитал такую ​​хранимую процедуру пустой тратой времени: - много усилий для минимальной выгоды - усложняет использование таких инструментов, как ORM, которые решают все более важные проблемы.