4

我有一个两难的问题，我希望你能有一些专家意见。

我有一个名为 CARDS 的表，其中有一列 STATUS。如果记录的状态从“下载”变为“发布”，我必须将记录引用插入到另一个名为 CARD_ASSIGNMENTS 的表中。此外，需要将记录添加到 CARD_ASSIGNMENTS 中的次数与扫描仪中的活动记录一样多。

换句话说，如果有两个活动的扫描仪，我将在 CARD_ASSIGNMENTS 中得到两条记录，如下所示：

ID   CARD_ID   SCANNER_ID   STATUS_ID
1    1         1            4
2    1         2            4

我的困境是我不太确定执行上述操作的最有效方法是什么。我考虑了以下选项：

  1. 从 PHP - 执行一个 UPDATE 查询，然后执行 INSERT 查询。
  2. 创建一个存储过程，它将负责更新 CARDS 记录并将记录添加到 CARD_ASSIGNMENTS 中。然后，只需从 PHP 调用该存储过程。
  3. 为 CARDS 表创建一个 ON UPDATE 触发器，该触发器将负责将 INSERTS 处理到 CARD_ASSIGNMENTS 表中。

PS。MySQL Fiddle上提供了我的数据库的简化版本

谢谢，
凯特

4

2 回答 2

4

Interesting question.

I'm going to give you clues about how to approach the problem.

So, you have to start by defining precisely three things:

  1. the expected functionality
  2. the access policy to the functionality
  3. the technical upgrade policy

Here I'll detail these points.

So, the first point is that you have to define your functionality. By doing so, you will be able to tell whether adding a card implies always, in all the possible paradigms (sorry for the pedantic word I can't find a more proper one) of your information system, that this card MUST exist in the other table according to the specifications you provided. This 1-1 functional link must be said TRUE or FALSE. This is really important. Said with other words, if there's at least one possibility that one day you don't want to copy that record to the other table, it means the trigger is a wrong solution, or at least it should be thought with an emergency mode (for example a variable inside that allows it to not get executed in some conditions) setup on.

Then comes the second point, about the access policy. You have to know whether the allowed accessing systems will do so by using your application layer or if they could develop their own (SAAS style). If so, your php layer will be useless and the stored procedure is an excellent option, since every single technical and business layer will go trough it yes or yes.

The last thing to know is whether you're possibly going to upgrade your php layer one day. In most of the cases the answer is yes. If so, you might have to modify the part containing this sql logic you're talking about. Then, having everything into a stored procedure vs storing it hardcoded into the php will definitely save you time, and improve stability.

Left brain right brain, I'm going to tell you my personal opinion afterall. I really love going with stored procedures but not using any triggers. If the environment allows it, I would go for an underlying batch, calling a set of defined stored procedures, concentrating the activity outside of the online scope.

The advantages are the following:

  • none or less risks of interruption of the online workflow since you reduce the number of operations
  • different schedule to alliviate the database load
  • more secure policy since executing the stored procedure requires only one grant, while using the same sql with php would require insert/update grants
  • better logging quality: you can have a log per job
  • better emergency response: when a job fails (if well thought) you can restart it, and that's it.

Long post, but that was interesting and I really wanted to share these ideas.

Cheers!

于 2013-05-10T19:21:27.023 回答
0

I would use triggers. Some developers say, that if you have too many triggers and stored procedures, the database lives its own life, that means you never know what is going to happen on insert, update etc. But in my opinion, triggers may help you a lot to keep database consistent, so even if someone inserts data directly from some administration tool, the integrity is still kept, because all necessary commands are executed. If you choose stored procedures, you would still have to know, that you need to call this procedure to insert any new data.

于 2013-05-10T19:21:33.207 回答