Это случай использования, в котором ограничение уникального ключа может отличаться в зависимости от учетной записи.Таким образом, ограничение дублирования не может быть реализовано с использованием ограничения первичного ключа / уникального ключа.
Предположим, у нас есть таблица T1 со столбцами C1, C2, C3, C4, C5, и у нас есть два счета A1 и A2.Данные A1 и A2 заносятся в одну таблицу T1.Но чтобы получить уникальную запись для счета А1, мы рассмотрим столбцы С1 и С2, а для счета А2 - С3 и С3.Точно так же мы можем использовать много учетных записей, каждый из которых имеет свой набор столбцов для идентификации уникальной записи.
Итак, у нас есть проверки в коде Java.Но если есть 2 дублирующих одновременных запроса, 2 потока Java видят, что элемент не существует, и они оба вставляют запись, что приводит к дублированию.Как я могу предотвратить такие дублирующие вставки?
Я могу предотвратить обновления, используя блокировки на уровне строк или оптимистичный параллелизм Hibernate.Я могу думать о блокировках на уровне таблицы, чтобы предотвратить такие вставки, но ограничивает производительность приложения, так как он также блокирует обновления.