触发器与检查约束答案

【问题标题】：Trigger vs. check constraint触发器与检查约束
【发布时间】：2013-08-26 22:12:43
【问题描述】：

我想在表格上添加字段级验证。有一个名为“account_number”的字段，该字段应始终通过“luhn”检查。我发现了一个名为“luhn_verify”的函数，它似乎可以正常工作（如果你有兴趣，谷歌一下）。它返回一个布尔值。我的问题是：

在 PostgreSQL 中使用触发器进行此验证与检查约束是否有任何主要的性能优势。

附加信息：

免责声明：

我觉得这可能已经被回答了，但我似乎找不到明确的答案。如果是这样，请标记为重复并参考原始问题/答案。

对于 dba 委员会来说可能是一个更好的问题。

【问题讨论】：

【解决方案1】：

经验法则是尽可能使用CHECK 约束。

A CHECK constraint 更快、更简单、更便携、需要更少的代码并且更不容易出错。例如，触发器很容易被其他触发器规避。

A TRIGGER is more complicated。当您必须时使用它，以满足更复杂的要求。

如果CHECK 约束对您的情况过于严格或导致重新加载转储时出现问题，您可以使用NOT VALID 修饰符作为中间立场（Postgres 9.2+）。并且，稍后可以选择VALIDATE。见：

【讨论】：

@Erwin 你认为在 PostgreSQL 9.x 中是否有一个检查约束，比如不为空？
@ErwinBrandstetter 永远正确！ stackoverflow.com/questions/19137811/…
@Erwin 以我的经验，postgres 在还原数据库时会以不同的方式处理检查约束和触发器，即可以忽略触发器但不能忽略检查约束，因此根据约束可能会面临更复杂的还原使用检查约束时。
@rozkosz：当然值得一提。从 Postgres 9.1 开始，您可以使用 NOT VALID 创建一个 CHECK 约束，这将允许一些余地。有了经过验证的检查约束，转储中的现有数据一开始就不应违反 CHECK 约束。
检查约束实际上更快吗？在 Postgres 中性能更高？我读过现代 RDBMS 使触发器与检查约束一样快。你有什么可以支持的吗？