Question

我正在为iPhone应用程序构建一个RESTful API。

当用户“签入”[在表中插入新行]时，我想从该插入中获取数据并调用web服务，该服务将根据该插入发送推送通知。

我能想到的唯一方法是通过触发器执行，或者使用实际的插入方法，在成功插入后，调用web服务。对我来说这似乎是个坏主意。

我想知道你是否对此有任何想法，或者是否有我没有想到的更好的方法。

Answer 1

即使技术上可以，这也不是一个好主意！触发器应该非常精简，并且绝对不应该涉及冗长的操作（Web服务调用肯定是这样）！重新思考你的架构——应该有更好的方法来做到这一点！

我的建议是，将“注意到”需要在触发器中调用web服务的任务与该web服务调用的实际执行分开。

类似于：

在触发器代码中，在表中插入一个“稍后调用Web服务”（只需＜code＞insert＜/code＞以保持精简和快速，仅此而已）
有一个异步服务（SQL作业，或者最好是Windows NT服务），它将这些调用与实际的触发器执行分开进行，并将从该web服务检索到的任何数据存储到数据库中的相应表中。

触发器是一件非常挑剔的事情-它应该总是非常快速、非常精简-最多执行一两次＜code＞INSERT＜/code＞-并且无论如何都要避免触发器中的游标或其他冗长的操作（如web服务调用）

Brent Ozar在十大开发人员错误无法扩展和触发器是他关注的第一件事！强烈推荐

Answer 2

这取决于业务需求。通常我会避免使用触发器，因为这是一个业务逻辑，应该由BL处理。

但你的问题的答案是肯定的——你可以这样做，只需确保异步调用web服务，这样它就不会在web服务调用完成时延迟插入。

您也可以考虑使用OneWay网络服务，即开火并忘记。

但是，正如其他人所指出的，你最好不要使用扳机。

如果架构正确，应该只有一段代码可以与数据库通信，即仅在单个服务中对DAL进行某种抽象。在插入后，用钩子钩住它，做任何需要的东西。

如果有许多不同的应用程序可以直接访问数据库而不是通过DAL服务在数据库中写入，我会使用触发器。这又是一场等待发生的灾难。

另一种情况是，如果我必须处理内部托管的第三方应用程序，即如果我可以访问数据库服务器本身，但不能访问写入数据库的代码，我可能会使用触发器。

Answer 3

存储过程呢？与其在触发器上设置它，不如调用一个存储过程，该过程将插入数据，并可能执行其他操作。

据我所知，触发器的作用域非常有限。存储过程可能有更大的作用域（也可能没有）。

在最坏的情况下，您总是可以构建自己的“API”页面；不是直接插入数据，而是请求API页面，该页面既可以插入数据，也可以进行推送通知。

Answer 4

触发器->；队列->；SP->；XP_XMDShell->；BAT->；cURL->；第三方web服务

I used a trigger to insert a record in a Queue table, then a Stored procedure using a cursor to pull Queued entries off.

我没有WSDL，也没有访问第三方API开发人员的权限，并且迫切需要完成原型，因此存储过程调用XP_CMDShell，调用带有参数的.bat文件。

bat文件调用cURL，cURL管理REST/JSON调用和响应。

它是免费的，快速的，工作可靠。虽然不是纯粹的建筑，但原型已经问世。

Answer 5

一个好的做法是，当用户点击该网页时，让该网页在另一个表中创建一个条目（我将调用message_queue）。

然后让服务器上的windows服务/*nix守护进程扫描message_queue表，并通过web服务向移动应用程序执行推送。您可以利用SQL中事务处理的功能来管理队列处理。

这种方法的好处是，您可以从一个独立的服务器上开始，甚至可以在扩展时将网站、数据库、服务/守护进程分离到不同的物理服务器或服务器集群上。