Database design 触发器与约束的性能注意事项

我正在尝试找出是否应该在数据库中的触发器或约束中使用业务关键型逻辑。
到目前为止，我已经在触发器中添加了逻辑，因为它让我可以控制接下来会发生什么，这意味着我可以提供自定义用户消息，而不是可能会让用户感到困惑的错误

---

使用约束优于触发器是否有明显的性能提升，以及确定使用哪种触发器的最佳实践是什么。

一般来说，我更喜欢约束，我的代码会捕获sql server错误，并向用户提供更友好的内容。

触发器可能会导致性能问题。几乎在同一时间，它们也成了维护的噩梦。您无法了解发生了什么和（另外！）应用程序的行为异常，存在“虚假”数据问题。[真的，它们是触发问题。]

没有最终用户直接接触SQL。他们使用应用程序。应用程序以比触发器更智能、更可维护的方式包含业务逻辑。将应用程序逻辑放入应用程序中。将数据放入数据库

除非你和你的“用户”没有共同的语言，否则你可以向他们解释违反约束的情况。另一种选择是——不解释——将一个简单的数据库变成一个问题，因为它将数据和应用程序代码合并成一个无法维护的泥潭

“如何确保每个人都正确使用数据模型？”

两种（半）技术

确保模型是正确的：它与现实世界的问题域相匹配。没有只有通过复杂的挥手解释、存储过程和触发器才能解决的黑客、解决方法或快捷方式

帮助定义应用程序的业务模型层。每个人共享和重用的应用程序代码层

a。另外，确保模型层满足人们的需求。如果模型层有正确的方法和集合，那么绕过它直接访问底层数据的动机就会减少。一般来说，如果模型是正确的，这不是一个深刻的问题

---

触发器是等待发生的火车失事。约束并非如此。

最佳实践：如果可以使用约束进行操作，请使用约束

触发器并不像它们被怀疑的那样糟糕（如果使用正确的话），尽管我总是尽可能使用约束在现代RDMS中，触发器的性能开销与约束相当（当然，这并不意味着有人不能在触发器中放置可怕的代码！）

有时，有必要使用触发器强制执行“复杂”约束，例如希望强制执行该约束，并且只填充表的两个外键字段中的一个（我在一些域模型中见过这种情况）

---

关于业务逻辑是否应该驻留在应用程序而不是数据库中的争论在某种程度上取决于环境；如果有许多应用程序访问数据库，那么约束和触发器都可以作为数据正确性的最终保障。

约束可以放手

• 通过约束，您可以指定关系原则，即有关数据的事实。除非某些事实发生变化（即新需求），否则您永远不需要更改约束

• 使用触发器可以指定如何处理数据（插入、更新等）。这是一种“非关系”的做事方式

用一个类比来更好地解释我自己：编写SQL查询的正确方法是指定“您想要什么”，而不是“如何获取”——让RDBMS为您找出最好的方法。同样的道理也适用于这里：如果你使用触发器，你必须记住各种事情，比如执行顺序、级联等等。。。如果可能的话，让SQL通过约束为您做到这一点

---

这并不是说触发器没有用途。确实如此：有时您不能使用约束来指定有关数据的某些事实。但这是极为罕见的。如果这种情况经常发生在您身上，那么模式可能存在一些问题。

约束和触发器适用于两种不同的情况。约束用于约束数据的域（有效输入）。例如，SSN将存储为char（9），但约束为[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]（均为数字）

触发器是在数据库中强制执行业务逻辑的一种方法。再次使用SSN，可能在SSN发生更改时需要保留审计跟踪-这将通过触发器完成

---

一般来说，现代RDBMS中的数据完整性问题可以通过某种约束的变化来处理。然而，您有时会遇到不正确的规范化（或更改的需求，导致现在不正确的规范化）阻止约束的情况。在这种情况下，触发器可能能够强制执行您的约束，但它对RDBMS是不透明的，这意味着它不能用于优化。这也是“隐藏”逻辑，可能是维护问题。在这一点上，决定是重构模式还是使用触发器是一个判断调用。

我同意这里每个人关于约束的看法。尽可能多地使用它们

有一种过度使用触发器的趋势，特别是对于新开发人员。我见过这样的情况：一个触发器触发另一个触发器，该触发器触发另一个重复第一个触发器的触发器，从而创建一个连接服务器的级联触发器。这是触发器的非最佳用户；o）

也就是说，触发器有其位置，应该在适当的时候使用。它们特别适合于跟踪数据的变化（正如马克·布莱克特所提到的）。您需要回答“将我的业务逻辑放在哪里最有意义”的问题？最