在过去的弱点中，我学到了很多关于触发器和事件数据库的知识，但我对这些的现实世界示例有一些疑问。
在工作中，我们将 Entity Framework 与 ASP.Net 和 MSSQL Server 结合使用。我们只使用自动生成的约束，没有触发器。
当我听说触发器时，我问自己以下问题:
触发器可以执行哪些任务？ 例如:报告数据的生成:目前报告的数据是在 vb 中创建的，但我认为触发器也可以处理这个问题。在 vb 中创建需要花费大量时间，用户不需要等待，因为这对于他的工作来说不是必需的。 这是触发器完美任务的示例吗？
OR-Mapper 如何处理触发器操纵的数据？ 例如:OR-Mapper 是否能够识别触发器是否操纵了数据？ Entity Framework 似乎缓存了大量数据，因此我不确定在处理框架的插入/更新/删除后，如果触发器操作数据，它是否会读取更新的数据。
数据库内应进行多少约束处理？ 例如:有时数据库中的约束看起来比上层(vb.net，...)更容易和更快，但是如何向 OR-Mapper 可以处理的上层抛出异常？ 是否有一个好的解决方案可以在任何 OR-Mapper 中处理 SQL 异常(来自触发器)？
提前致谢
最佳答案
当您听说新工具或功能时，并不意味着您必须在任何地方使用它。您应该考虑应用程序的设计。
当逻辑位于数据库中时，触发器会被大量使用，但如果您在数据库之上构建 ORM 层，则需要使用 ORM 在业务层中使用逻辑。这并不意味着您不应该使用触发器。这意味着您应该以与存储过程或数据库函数相同的方式将它们与 ORM 一起使用 - 仅当它有意义或可以提高性能时。如果你将大量逻辑传递给数据库，你可以抛弃 ORM，甚至整个业务层，并使用两层架构，其中 UI 将直接与数据库对话，数据库将完成你需要的一切 - 这种架构被认为是“旧的”。
- 使用 ORM 触发器对于某些数据库生成的数据(例如审核列或主键值的自定义序列)很有帮助。
- 当前的 ORM 大多不喜欢触发器 - 它们只能对当前处理的记录的更改使用react，因此例如，如果您保存订单记录并且您的更新触发器将修改所有订购的项目，则没有自动方式让 ORM 知道这一点- 您必须手动重新加载数据。在 EF 中，数据库中修改或生成的所有数据都必须使用 StoreGeneratePattern.Identity 或 StoreGeneratePattern.Compulated 进行设置 - EF 完全遵循逻辑位于数据库或数据库中的模式。应用。一旦您定义了在数据库中分配的值，您就无法在应用程序中更改它(它将不会持久)。
- 您的应用程序逻辑应负责数据验证，并仅在验证通过时调用持久性。当您预先知道事务将会失败时，您应该避免不必要的事务和数据库往返。
关于sql - 如何在实际项目中使用数据库触发器？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6479040/