Лучший способ проверить дубликаты записей в базе данных | зимовать

1

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

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

Также необходимо соблюдать следующие пункты

  1. Необходимо создать такое же количество объектов подарочной карты, как это требуется администратором
  2. Чтобы следовать пункту 1, нам нужно найти, какой код подарочной карты уже существует в БД, и нужно снова генерировать код.

Я использую Hibernate для операций с БД, и у меня есть следующие параметры.

Первый вариант

  1. Создать список подарочных карт
  2. начните создание объекта для каждого кода подарочной карты и попробуйте вставить их в БД.
  3. Если мы обнаружили какое-либо исключение для существующего объекта подарочной карты, сохраните этот код в отброшенном списке кодов.
  4. Снова повторить процесс для отброшенного списка

Второй вариант

  1. Создайте список подарочных карточных кодов.
  2. Проверяйте дубликаты кодов в БД перед созданием сущностей подарочных карт.
  3. Для отброшенного списка снова создайте код подарочной карты и следуйте пункту 2.
  4. Для окончательного списка создайте сущности и вставьте в DB

Я немного смущен, какой подход должен быть предпочтительным?

  • 0
    Как насчет триггера базы данных, который генерирует коды вместо этого?
  • 0
    @Kayaman: Нет, нам нужен определенный шаблон с этими кодами, такими как длина кода, алфавит, цифра и т. Д.
Показать ещё 3 комментария
Теги:
hibernate
jpa
jpa-2.0

2 ответа

1

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

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

  • 0
    Спасибо за ваш вклад, хотя код наверняка будет уникальным в БД, и я также немного склонен к варианту 1.
  • 0
    Единственное, на что нужно обратить внимание - это на обработку транзакций, если у вас есть большой пакет кодов для генерации, вы не хотите, чтобы транзакция откатывалась только на один плохой код
0

Я бы создал все, а затем проверял дублированные значения с помощью JPQL lilke:

select p from Ticket p where p.id in (:idList)

При такой "пакетной" операции вам не нужно будет совершать поездку в базу данных на каждой итерации. Это проблема вашего первого варианта.

Если вы используете somekind правила базы данных, например: ограничение или триггер, вы можете получить исключение, которое может привести к откату транзакции.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню