Уникальное ключевое ограничение - PullRequest
2 голосов
/ 20 декабря 2010

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

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

Плюсы

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

Против

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

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

Плюсы

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

Против

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

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

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

Спасибо!

Ответы [ 4 ]

3 голосов
/ 20 декабря 2010

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

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

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

2 голосов
/ 20 декабря 2010

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

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

1 голос
/ 20 декабря 2010

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

1 голос
/ 20 декабря 2010

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

...