У меня есть экран создания пользователя, который принимает различные данные пользователя вместе с именем и номером мобильного телефона. У меня есть соответствующая таблица USER, в которой имя и номер мобильного телефона образуют составной уникальный ключ. Существуют и другие ограничения целостности, определенные в этой таблице.База данных - обработка уникального нарушения ограничений
Когда пользовательские данные вводятся на экране «Создать пользователя», который нарушает это ограничение, пользователю необходимо показать сообщение об ошибке «user friendly».
Когда происходит такое нарушение, исключение, которое я получаю из базы данных MySQL является:
com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '1-1' for key `uk_FIRST_NAME__MOBILE_idx`
Есть два варианта, чтобы показать значимое сообщение (например: «ОШИБКА: Имя пользователя уже существует для данный мобильный номер, пожалуйста, измените один из них »).
Вариант 1: В блоке catch этого исключения проанализируйте сообщение об ошибке MySQL и найдите «uk_FIRST_NAME__MOBILE_idx». Если есть, покажите дружественное пользователю сообщение, как указано выше.
Вариант 2: Напишите API уровня DAO, который будет принимать первое имя и номер мобильного телефона только в качестве двух параметров, и вызовет запрос базы данных, чтобы увидеть, существует ли существующая запись, соответствующая этому имени/мобильной комбинации. Если значение true, покажите сообщение об ошибке пользователю; else, запустите запрос вставки, чтобы вставить пользователя записи в таблицу USER.
Мне не нравится вариант 1, так как мне нужно «разобрать» сообщение об исключении, которое не является чистым решением. Мне также не нравится вариант 2, так как мне нужно запустить «два запроса» в базе данных, которая менее эффективна, чем вариант 1, который является единственным решением для запросов.
Вопрос: Есть ли другие варианты, которые лучше этих двух? Если нет, то какой из них является правильным подходом к этим двум?
I * обычно * найти его чистейших в этих случаях в первую «проверить», чтобы убедиться, что имя пользователя (или любые ограничения) действительны/разрешено, а затем попробовать фактическое обновление и выставить его через DAL - это также полезно обеспечить «проверку в реальном времени» данных (например, предупреждения валидации). В условиях небольшой гонки исключение вставки можно рассматривать только как «Мы сожалеем, повторите попытку!». То есть, база данных является защищенной сетью, но не несет ответственности за сообщения об ошибках конечных пользователей. – user2864740
Спасибо за указание возможности «гонки» в опции 2. – PhantomReference