Избегание исключения - это, как правило, хорошая идея - бросание исключения является довольно сложной и затратной и ресурсоемкой работой. Поэтому, если вы можете легко проверить, существует ли уникальное значение ключа, я бы, вероятно, это сделал. Предполагая, что у вас есть уникальный индекс или уникальное ограничение для этого столбца на уровне базы данных, тогда (по крайней мере для SQL Server) уже есть индекс в этом столбце, поэтому проверка на конкретное значение будет довольно простой и не будет иметь большой производительности влияние.
Другой вопрос: как часто вы думаете, что это произойдет? Один раз в день? Раз в две недели? Несколько раз в минуту? Если это случается только довольно редко - однажды в голубой луне, я бы не стал пытаться проверить сначала - в этом случае, просто пусть исключение произойдет и обработает его.
Итак, я думаю, что это действительно вопрос того, насколько дорого стоит проверять в первую очередь и как часто это происходит? Если вы можете проверить это очень легко -> сделайте это, во что бы то ни стало! Но если это довольно сложная операция для проверки, и это происходит очень редко, тогда просто обработайте исключение.
Спасибо за здравый смысл ответа; это в значительной степени то, о чем я думал. Поскольку в этом случае нарушения ограничений встречаются редко, я оставлю это как есть. –
Хммм ... Я не могу согласиться. Выброс исключения - это * не * столь же дорого, как запрос к базе данных. Тем не менее, вы должны запросить базу данных до операции вставки/обновления, что может привести к уникальному нарушению ограничения. – CodeMonkeyKing
@CodeMonkeyKing Вот в чем смысл. Если вы запрашиваете базу данных перед вставкой, вы будете ВСЕГДА иметь и дополнительные штрафные санкции за раунд, и даже в этом случае между вашими запросами и недействительными будет первая вставка. Как сказал Марк, проверьте, редки ли эти исключения в вашей системе, и если да, просто дайте базе данных справиться с этим. – andrecarlucci