Должен ли я проверить уникальное ограничение с помощью php?

Question

Возможно, этот вопрос уже задан, но я не знаю, как его искать:

У меня есть клиенты postgres-table «клиенты», и каждый клиент имеет свое собственное уникальное имя. Чтобы достичь этого, я добавил уникальное ограничение в этот столбец.

Доступ к таблице с php.

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

Что я хочу сделать, это показать ошибку в поле ввода html: «Имя клиента уже принято», когда это произойдет.

Мой вопрос в том, как я должен это делать.

Должен ли я поймать PDO-исключение, проверьте, является ли код ошибки «УНИКАЛЬНЫМ НАРУШЕНИЕМ», а не отображает сообщение в соответствии с Exception-Message, или я должен проверять наличие дубликатов имен с дополнительным заявлением до того, попробуйте вставить новую строку?

Что лучше? Создание еще одного sql-оператора, или поиск и анализ кодов ошибок.

EDIT: Я использую транзакции, и я предпочитаю исключение для отката. Вопрос в том, должен ли я отфильтровывать уникальные нарушения, чтобы они не приводили к откату.

EDIT2: Если я использую исключение-метод, я должен был бы проанализировать исключение-сообщение для того, чтобы гарантировать, что единственное ограничение, на самом деле принадлежит «имя» -column.

Это все, что я получаю от за исключением:

["23505",7,"FEHLER: doppelter Schlüsselwert verletzt Unique-Constraint <customers_name_unique>\nDETAIL: Schlüssel <(name)=(test)> existiert bereits."] 

Единственный способ получить информацию о столбце, чтобы проверить, если «customers_name_unique» существует (это название уникального-ограничения).

Но, как вы можете видеть, сообщение находится на немецком языке, поэтому выход зависит от системы/может быть изменен.

Answer 1

Вопрос здесь не совсем, но я отвечу вам.

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

Answer 2

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

Answer 3

Я бы выбрал исключение, потому что (благодаря параллелизму), которое может случиться в любом случае, даже если вы предварительно проверите дополнительный запрос.

Answer 4

На SAVE проверьте, существует ли (простое поле, в вашем случае: столбец ограничений). Если утвердительно - сообщите пользователю о дублировании уведомления. Но не заставляйте сервер БД возвращать вам исключения.

Answer 5

Вы должны поймать исключение PDO.

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

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

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