Проверка аргументов хранимых процедур для обеспечения ограничений ссылочной целостности

Question

В последнее время у меня есть тенденция проверять аргументы запроса действия хранимой процедуры перед тем, как фактически выполнить запрос. Примером может быть проверка того, что при обновлении таблицы «T» со столбцом «C» с уникальным индексом обновление не завершится ошибкой ... сначала выполнив тип «Выбрать существует по уникальному индексу» запроса до фактического обновления. Если уникальный индекс будет нарушен, то я рано фиксирую ошибку и возвращаюсь.

Я в основном построил свою обычную оптимистическую стратегию блокировки, заключающуюся в том, что проверяемая мной запись все еще имеет право на обновление, т. Е. Не изменилась. Я сделал еще один шаг, проверив, что уникальный индекс не будет нарушен, если я выполню обновление.

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

У кого-нибудь есть здравый совет в этой области?

Меня также интересуют подходы других людей к валидации параметров в целом.

Answer 1

Мне кажется, что это лишняя работа.

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

Добавлена ​​

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