SQLとMySQLでストアドプロシージャを作成する利点は何ですか？
理論的な質問があります。
PHPファイル内で関数を宣言することと、同じことを行うデータベースでストアドプロシージャを作成することの違いはわかりません。事。
PHPで実行できるのに、たとえば、特定の国のすべての都市のリストを返すためにストアドプロシージャを作成したいのはなぜですか？ functionデータベースにクエリを実行すると、同じ結果になりますか？
この場合、ストアドプロシージャを使用する利点は何ですか？それともどちらが良いですか？データベース内でPHPまたはストアドプロシージャ）の関数を使用するには？そして、2つの違いは何ですか？
ありがとうございました。
いくつかの利点が含まれます：
保守性：app1、app2、およびapp3の呼び出しを編集しなくても、プロシージャのロジックを変更できます。
セキュリティ/アクセス制御：誰がどのテーブルまたはどのテーブル行にアクセスできるかを制御するよりも、誰が事前定義されたプロシージャを呼び出すことができるかを心配する方が簡単です。
パフォーマンス：アプリがDBと同じサーバー上になく、実行している操作に複数のクエリが含まれる場合、プロシージャを使用すると、データベースへの呼び出しがいくつでも行われるのではなく、データベースへの呼び出しが1回行われるため、ネットワークのオーバーヘッドが削減されます。クエリ。
パフォーマンス（2）：プロシージャのクエリプランは通常キャッシュされているため、再準備しなくても何度でも再利用できます。
（あなたの特定の例の場合、利益は確かにゼロです。）
簡単な答えは、コードを移植可能にしたい場合は、ストアドプロシージャを使用しないでください。たとえば、MySQLからPostgreSQLにデータベースを変更する場合は、作成したすべてのストアドプロシージャを更新/移植する必要があるためです。
一方、すべてのコードはデータベースエンジンによって実行されるため、ストアドプロシージャを使用すると、パフォーマンスの結果が向上する場合があります。また、ストアドプロシージャが不適切に使用されると、状況が悪化する可能性があります。
国の選択は非常に費用のかかる操作だとは思いません。したがって、この場合はストアドプロシージャを使用する必要はないと思います。
ほとんどの人がすでにそれを説明しているように、それでも私は自分のやり方で繰り返してみようと思います
ストアドプロシージャ：
ロジックはデータベースにあります。
実行する必要のあるクエリを考えてみましょう。次のいずれかの方法で実行できます。
- クライアントからデータベースサーバーにクエリを送信します。ここでクエリが解析、コンパイルされ、実行されます。
もう1つの方法は、データベースサーバーにクエリを配置し、クエリのエイリアスを作成することです。このエイリアスを使用して、クライアントはデータベースサーバーにリクエストを送信し、サーバーで受信すると実行されます。
だから私たちは持っています：
クライアント-------------------------------------------- -------------->サーバー従来型：
クエリは@Clientを作成しました----------次にサーバーに伝播します----------クエリ：到達したサーバー：解析、コンパイル、実行。ストアドプロシージャ：
エイリアスが作成され、クライアントによって使用されます----------------次にサーバーに伝播します--------エイリアスがサーバーに到達しました：解析、コンパイル、キャッシュ（初めて）
次に同じエイリアスが表示されたら、クエリ実行可能ファイルを直接実行します。利点：
ネットワークトラフィックの削減：クライアントが大きなクエリを送信していて、同じクエリを頻繁に使用している可能性がある場合、クエリのすべてのビットがネットワークに送信されますしたがって、ネットワークトラフィックが増加し、不必要にネットワーク使用量が増加する可能性があります。
より高速なクエリ実行：ストアドプロシージャが解析され、一度にコンパイルされ、実行可能ファイルがデータベースにキャッシュされるため。したがって、同じクエリが複数回繰り返される場合、データベースは実行可能ファイルを直接実行するため、時間は解析、コンパイルなどに保存されます。これは、クエリが頻繁に使用される場合に適しています。クエリが頻繁に使用されない場合は、キャッシュされた実行可能ファイルの保存にスペースが必要になるため、データベースに不必要に負荷をかけるのは適切ではない可能性があります。
Modular：複数のアプリケーションが同じクエリを使用したい場合、従来の方法では、アプリケーションで不必要にコードを複製するのが最善の方法です。データベースに近いため、この方法で重複を簡単に軽減できます。
セキュリティ：承認（クエリを実行する権限があるユーザーとそうでないユーザーを意味します）を念頭に置いて、ストアドプロシージャも開発されています。アクセス許可を付与できるユーザー、DBAがアクセス許可を取り消すことができる他のユーザー。したがって、DBAへのポイントとしては良い方法ですDBAは、誰がアクセスを取得するのに適切な人であるかを知ることができますが、そのようなものは現在それほど人気がないので、許可された人だけがアクセスできるようにアプリケーションデータベースを設計できます。すべて。したがって、従来の方法ではなくストアドプロシージャを使用するポイントとしてセキュリティ/承認しかない場合は、ストアドプロシージャが適切でない可能性があります。
わかりました、これは少し単純化されすぎているかもしれません（そしておそらく不完全です）：
ストアドプロシージャの場合：
- クエリをデータベースに送信する必要はありません
- dBMSは毎回クエリを検証する必要はありません（構文の意味で検証するなど）
- dBMSは毎回クエリを最適化する必要はありません（SQLは宣言型であるため、DBMSは最適化されたクエリ実行プランを生成する必要があります）