[通信] なぜSQLでストアドプロシージャを使うのか、そしてその利点は何ですか?

私の意見では、ストアドプロシージャは単にSQLの統合の集合体です。 途中で少し論理制御が加えられています。

しかし、より複雑なビジネスを扱う場合にはストアドプロシージャの方が有用です。
例えば、複雑なデータ操作です。 フロントで対応すれば。 複数のデータベース接続が関与している場合があります。 しかし、ストアドプロシージャを使う場合は 一度だけ。 応答時間という点で利点があります。
言い換えれば、ストアドプロシージャは運用効率の向上という利点をもたらします。
さらに、プログラムはバグの不安定さやストアドプロシージャが起こりやすく、データベースの問題がなければ基本的に問題は起こりません。 言い換えれば、セキュリティの観点からはストアドプロシージャを使うシステムはより安定しています。

データ量が少なかったり、資金に関係のないプロジェクトでも、ストアドプロシージャなしで通常通り動作できます。 MySQLのストアドプロシージャはまだ実際にテストされていません。 正式なプロジェクトの場合は、SQL ServerやOracleのストアドプロシージャを使用することが推奨されます。 データからデータへのやり取りでは、プログラムよりもはるかに高速です。 面接官はストレージがあるかどうか尋ね、実は面接に来たプログラマーが大量のデータを持つプロジェクトを行ったかどうかを知りたかったのです。 もし訓練されていれば、小規模なプロジェクトや小規模な会社であれば、保管との接触は確実に減ります。

したがって、大企業に入りたい場合、保管プロセスの豊富な経験なしにはできません。

では、ストレージはいつ使えるのでしょうか? データ量があまり大きくなく、ビジネス処理もそれほど複雑でない小規模プロジェクトでは、必要ではないのでしょうか?
違う。 ストアドプロシージャは大規模プロジェクトだけでなく、小規模・中規模のプロジェクトにも適しており、ストアドプロシージャの使用も非常に重要です。 その力と利点は主に以下に反映されています:
  1. ストアドプロシージャは作成時にのみコンパイルされ、今後のストアドプロシージャ実行のたびに再コンパイルする必要がありません。一方、一般的なSQL文は実行されるたびにコンパイルされるため、ストアドプロシージャを使用することでデータベースの実行速度が向上します。
  2. データベース上で複雑な操作(複数のテーブルの更新、挿入、クエリ、削除など)を行う際、この複雑な操作はストアドプロシージャにカプセル化され、データベースが提供するトランザクション処理と組み合わせて使用できます。 これらの操作はプログラム的に行われる場合、複数のデータベース接続を必要とするSQL文となります。 ストレージの代わりに、データベースには一度だけ接続すれば十分です。
  3. ストアドプロシージャは再利用可能であり、これによりデータベース開発者の作業負荷が軽減されます。
  4. 高いセキュリティで、指定された保存プロセスを使用する権利を持つのはこのユーザーのみ。