Лучший способ ответить на этот вопрос - разделить его на две идеи.
1) Где в конечном итоге применяется уникальное ограничение? В этом случае (из вашего вопроса) ответом является база данных.
2) Как мы можем улучшить взаимодействие с пользователем, проверяя ограничения в других местах?
Поскольку база данных в конечном итоге примет решение в рамках транзакции , никакой полезной проверки вы не сможете сделать заранее. Даже если вы проверяете перед вставкой, возможно (хотя обычно это маловероятно), чтобы другой пользователь вставил это значение во времени между проверкой и фактической вставкой.
Так что пусть база данных решит и отправит сообщение об ошибке обратно в интерфейс.
Обратите внимание, что это не всегда верно для всех ограничений. При проверке внешних ключей для небольших таблиц (таких как таблица штатов США или стран или провинций) пользовательский интерфейс предоставляет пользователю список выбора, который вынуждает пользователя выбирать допустимое значение. В этом случае пользовательский интерфейс действительно применяет ограничение. Хотя, конечно, даже в этом случае база данных должна принять окончательное решение, чтобы защитить себя от вредоносных запросов к веб-уровню, созданных вручную, которые намеренно пытаются ввести недопустимые значения.
Итак, для некоторых ограничений, да, пусть поможет пользовательский интерфейс. Но для уникальных ограничений пользовательский интерфейс действительно не может помочь, потому что база данных является окончательным авторитетом, и нет никакой полезной проверки, которую вы можете гарантировать, что вы гарантированно останетесь верным, когда вы сделаете вставку.