逻辑：数据库或应用程序/ 2（约束检查）

这是this question的特定版本。
我想检查我是否插入重复行。我应该以编程方式检查它在我的应用程序层：逻辑：数据库或应用程序/ 2（约束检查）

if (exists(obj)) 
{ 
    throw new DuplicateObjectException(); 
} 
HibernateSessionFactory.getSession().save(obj);

，或者我应该赶在数据库层抛出，引发异常时，我违反了该限制？

try 
{ 
    HibernateSessionFactory.getSession().save(obj); 
} 
catch(ConstraintViolationException e) 
{ 
    throw new DuplicateObjectException(); 
}

编辑：换句话说：虽然约束是有保留（这是很好的数据库设计，无论如何，我不能肯定我的应用程序将是唯一一个访问表）应我靠在约束条件下处理违规行为将会引发的异常，或者我最好还是检查一下？

EDIT2：当然，我做检查+在事务内插入，锁表，以确保没有其他进程正在写另一个纪录同时

来源

2008-10-03 Manrico Corazzi

首先，您需要必须有一个主键或唯一的限制在数据库以正确执行此唯一性 - 没有问题。

鉴于约束存在，你应该在应用程序代码哪种方式？我喜欢尝试插入并捕获异常。因为大概大多数插入操作都会成功，所以只有少数插入操作会失败，因为重复项（这就是“异常”意味着什么！）：在数据库将要执行自己的约束检查时，在每次插入之前执行存在检查效率不高。

而且，它在理论上是可能的存在检查是错误的呢 - 如果有人设法犯了相同键值的记录在小间隔间存在的检查，您的插入。然后，如果你不捕获数据库异常，你会相信插入成功，但实际上并不成功。

来源

2008-10-03 14:44:03

在一般情况下，我会尽量避免编码依赖错误被抛出是因为我做错了什么。但有时候，这就是你所能做的。在你的情况下，我认为你应该先检查一下。

来源

2008-10-03 14:36:25 wcm

你需要捕捉数据库例外，除非你能保证你的应用程序是有史以来插入行（和以往任何时候都将插入行）到你的数据库的唯一一个。

编辑：我可能误解了这个问题，但我仍然认为选项B（HibernateSessionFactory抛出数据库中的ConstraintException）是更好的选择。另一个应用程序可能会在检查和实际函数调用之间的时间间隔中插入一些东西，这总是有一点小概率。另外，检查重复的唯一方法是执行额外的查询，这只是性能上不必要的消耗。

我的问题的独到理解是，在选择A的欺骗检查将在内部进行（即仅使用该程序已经创建的数据结构，并没有询问，直到INSERT）。我原来的回答是回应这种方法。

来源

2008-10-03 14:37:45 JPLemme

这将打破（允许重复的条目），如果约束被丢弃由于某种原因（一般维修工作，其中DBA忽略重新启用它）。你应该检查应用程序中的这种情况。

但是，数据库设计的好处是让数据库强制实施约束（正如您已经正确指出的那样），因为其他人也可能正在使用该数据库。作为概括，最好假定应用程序和数据库存在M：M关系 - 几乎所有情况都是如此。

来源

2008-10-03 14:56:14 ConcernedOfTunbridgeWells