4

私にはジレンマがあります。専門家の意見をお聞かせいただければ幸いです。

列 STATUS を持つ CARDS というテーブルがあります。レコードのステータスが「ダウンロード」から「公開」に変わった場合、レコード参照を CARD_ASSIGNMENTS という別のテーブルに挿入する必要があります。さらに、SCANNERS にアクティブなレコードがあるのと同じ回数、レコードを CARD_ASSIGNMENTS に追加する必要があります。

つまり、アクティブなスキャナーが 2 つある場合、以下のように CARD_ASSIGNMENTS に 2 つのレコードが作成されます。

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

私のジレンマは、上記を実行する最も効率的な方法が何であるかがよくわからないことです。次のオプションを検討しました。

  1. PHP から - UPDATE クエリを 1 回実行してから、INSERT クエリを実行します。
  2. CARDS レコードの更新と CARD_ASSIGNMENTS へのレコードの追加を処理するストアド プロシージャを作成します。次に、そのストアド プロシージャを PHP から呼び出すだけです。
  3. CARD_ASSIGNMENTS テーブルへの INSERTS の処理を​​処理する CARDS テーブルの ON UPDATE トリガーを作成します。

PS。私のデータベースの簡略化されたバージョンは、MySQL Fiddleで入手できます

ありがとう、
ケイト

4

2 に答える 2

4

興味深い質問です。

問題へのアプローチ方法について手がかりを提供します。

したがって、次の 3 つのことを正確に定義することから始めなければなりません。

  1. 期待される機能
  2. 機能へのアクセス ポリシー
  3. 技術アップグレード ポリシー

ここでは、これらのポイントについて詳しく説明します。

したがって、最初のポイントは、機能を定義する必要があるということです。そうすることで、カードを追加することが、情報システムのすべての可能なパラダイム (より適切なパラダイムを見つけられないペダンティックな言葉で申し訳ありません) において、このカードが常に存在しなければならないことを意味するかどうかを伝えることができます。あなたが提供した仕様に従って他のテーブル。この 1 対 1 の機能リンクは、TRUE または FALSE である必要があります。これは本当に重要です。言い換えれば、ある日そのレコードを別のテーブルにコピーしたくないという可能性が少なくとも1つある場合、それはトリガーが間違った解決策であることを意味するか、少なくとも緊急モードで考えるべきです（たとえば、いくつかの条件で実行されないようにする内部の変数) を設定します。

次に、アクセス ポリシーに関する 2 番目のポイントです。許可されたアクセス システムがアプリケーション層を使用してそうするかどうか、またはシステムが独自に開発できるか (SAAS スタイル) を知る必要があります。もしそうなら、php レイヤーは役に立たず、ストアド プロシージャは優れたオプションです。すべての技術およびビジネス レイヤーが「はい」または「はい」を通過するからです。

最後に知っておくべきことは、いつか PHP レイヤーをアップグレードする可能性があるかどうかです。ほとんどの場合、答えはイエスです。もしそうなら、あなたが話しているこのSQLロジックを含む部分を変更する必要があるかもしれません. 次に、ストアド プロシージャにすべてを格納するのではなく、php にハードコーディングすることで、確実に時間を節約し、安定性を向上させることができます。

左脳右脳、やっぱり個人的な意見を言います。私はストアド プロシージャを使用するのが大好きですが、トリガーは使用しません。環境が許せば、基盤となるバッチを使用し、一連の定義済みストアド プロシージャを呼び出して、オンライン スコープ外のアクティビティを集中させます。

利点は次のとおりです。

  • 操作の数を減らすため、オンライン ワークフローが中断されるリスクがまったくないか、または少なくなります。
  • データベースの負荷を軽減するための別のスケジュール
  • ストアド プロシージャの実行に必要な権限は 1 つだけであり、PHP で同じ SQL を使用する場合は挿入/更新権限が必要になるため、より安全なポリシー
  • ログ品質の向上: ジョブごとにログを作成できます
  • より良い緊急対応: ジョブが失敗した場合 (よく考えれば)、ジョブを再開できます。それだけです。

長い投稿ですが、それは興味深いものだったので、これらのアイデアを共有したいと思いました.

乾杯！

于 2013-05-10T19:21:27.023 に答える
0

トリガーを使用します。一部の開発者は、トリガーとストアド プロシージャが多すぎると、データベースはそれ自体で機能し、挿入や更新などで何が起こるかわからないと言っています。しかし、私の意見では、トリガーはデータベースの一貫性を保つため、誰かが何らかの管理ツールから直接データを挿入したとしても、必要なすべてのコマンドが実行されるため、整合性は維持されます。ストアド プロシージャを選択した場合でも、このプロシージャを呼び出して新しいデータを挿入する必要があることを知っておく必要があります。

于 2013-05-10T19:21:33.207 に答える