Уникальное ключевое ограничение

Question

Каков наилучший способ обработки вставки / обновления данных в таблицу с ограничениями уникального ключа на уровне приложения ? Вот что я придумал:

1. Запустите запрос к таблице перед вставкой данных, чтобы посмотреть, не нарушит ли это ограничение.

Плюсы

• У вас есть полный контроль, поэтому вам не нужно иметь дело с сообщениями об ошибках, специфичными для СУБД.
• Дополнительный уровень проверки целостности данных

Против

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

2. Ничего не делать. Обновите таблицу и посмотрите, что прилипает.

Плюсы

• Simple!
• В целом быстрее, так как вам не нужно запускать дополнительный запрос при каждом обновлении таблицы.

Против

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

Какое из них является наиболее широко принятым решением? Есть ли альтернативы этим?

Я использую Java, JPA, Hibernate и Spring BTW. Любые предложения, даже специфичные для фреймворка, приветствуются!

Спасибо!

Answer 1

Вы уже подвели итог.Если производительность является проблемой, перейдите на второй путь.Если честность вызывает беспокойство, идите по 1-му пути.

Я лично предпочитаю честность, а не производительность.Аппаратное обеспечение довольно дешевое, целостности нет.

Вопросы, связанные с этим:

• Java - обработка нарушений целостности MySQL

Answer 2

Третий вариант - использовать операцию MERGE (иногда называемую UPSERT), если ваша СУБД поддерживает это.Обычно для СУБД существует особый способ проверки, была ли вставлена ​​строка или нет.

Избегайте тавтологического "уникального" ключа.Ключи уникальны, поэтому слова «ключ» вполне достаточно, чтобы сказать, что вы имеете в виду.

Answer 3

Уникальный ключ обычно является бизнес-требованием, поэтому вы должны использовать бизнес-уровень, чтобы проверить, доступен ли тот, который вы намереваетесь использовать. Передача проверки в базу данных является оптимизацией, которая должна выполняться только при необходимости.

Answer 4

Мне нравится «оптимистический» подход («ничего не делать»). Вы уже перечислили плюсы. Вы правы, что в этом случае вы делегируете валидацию слою БД. Но если вы используете JPA, слой БД также генерируется Java-слоем, поэтому фактически ваша проверка зависит от вашей аннотации в Java-коде. Поэтому это не большое преступление.