Sql 触发器或SP：在我的案例中应该使用什么？

我有一个由我们公司其他团队编写的应用程序，它在一个表中插入数据。 假设他们使用字段将数据写入表Log1：

• Id（自动生成的主键）
• KeyId
• 价值1
• 价值2
• 价值3

现在，我需要在另一个表（Log2）中有另一条记录，它们只有一部分数据：

• Id（它将是我自己自动生成的Id）
• KeyId
• 价值1

我认为有两种方法可以做到这一点：

创建触发器，在将记录添加到Log1时，将自动在Log2中创建具有所需数据的记录

实现SP，该SP将接受Log1表所需的所有数据，并在两个表中创建记录，然后要求这些应用程序作者使用SP而不是直接插入查询

在这种情况下，你认为什么是最好的方法？为什么

非常感谢你的帮助

另外，我正在使用MS SQL 2005

使用选项2

应尽可能避免触发

一个不太明显的原因：您是否使用过SQL Server复制工具？触发器不会很容易复制。（也就是说，这不像点击几下那么容易，比如说，对桌子来说）。但我要偏离主题了。。。总之，触发因素是邪恶的。。。尽量避免

编辑

更多原因：触发器不像DBMS中的其他对象那样容易看到。在应用程序方面，它们是不可见的，如果没有很好的文档记录，它们往往会被遗忘。如果架构发生更改。。。哦，使用存储过程维护东西更容易。

使用选项1

---

这意味着即使不使用“正确”的存储过程接口，表也将正确同步，插入多行将更容易、更高效（在SQL Server 2005中，存储过程如何实现这一点？—多次调用？首先将所有数据转换为XML格式？）真正保证数据完整性的唯一方法是使用触发器。总有可能有人会执行绕过SP的操作（批量操作、sql insert语句等）。

如果使用触发器，请注意，由于Log1和Log2似乎都使用标识列，因此不能使用

SELECT@@identity

返回Log1的PK-您需要使用

SCOPE\u identity（）

---

另一方面，如果您使用存储过程，您可以做的是从（几乎）所有人那里撤销对表的插入权限，而是在存储过程中授予EXEC。通过这种方式访问您的表应该得到很好的保护。

是否愿意分享为什么应该避免触发？我没有使用复制，并且不认为我们在可观察的未来（2-4年）需要这样做。我们不会批量进行操作。如果需要，我们会给SP打几次电话。我最喜欢这个主意。问题是，在我们的情况下，我不习惯关心权限等。。。