php5 と mysql5 を使用している場合、プリペアド ステートメントよりもストアド プロシージャを使用する利点はありますか? (mysql5ストアドプロシージャから実質的なパフォーマンスの向上が得られない可能性がある場所を読んだ)
JOhn
質問する
21712 次
7 に答える
29
これらは実際には同じではありません。ストアド プロシージャを使用すると、データベース ロジックはデータベース内に存在します。プリペアド ステートメントは基本的に、複数回呼び出された場合にクエリの再解析を回避します。パフォーマンスのメリットは大きく異なる可能性があります。
どちらを使用するかは、特定の状況によって異なります。すべてのロジックを 1 か所にまとめたいので、ストアド プロシージャはあまり使用しません。
于 2008-10-13T04:02:02.300 に答える
26
ストアドプロシージャは、次のようなプロフェッショナルグレード（IEエンタープライズグレード）のアプリケーションに適しています。
- データベースエンジニアがパフォーマンスのためにクエリを最適化できるようにしたい
- クエリの複雑さを単純なAPIに抽象化したい
- データベースで発生することの一部は、他の当事者に公開したくない知的財産である可能性があるため、ロジックを分散させたい
- 分散されたn層コンピューティングの性質であるため、ロジックを分散させたい
- データベースエンジニアまたはDBAに、アプリケーションコードを変更せずにスキーマを変更してもらいたい場合があります（ストアドプロシージャは、APIを提供することにより、抽象化レイヤーを提供します）
他にも理由があります。
準備されたステートメントは、セッション内で行われる作業に適しています。ただし、プリペアドステートメントの作成に時間をかけている場合は、基本的に、ストアドプロシージャの作成に必要なすべてのことを実行しています。違いは、ストアドプロシージャが複数のセッションで使用できることです（データベースのGRANTSの対象となります）。
私が理解できないのは、ストアドプロシージャとプリペアドステートメントのオプションがある場合、なぜプリペアドステートメントを気にするのかということです。SPとPSの議論のほとんどは、どちらを使用するのかではなく、それらの違いに焦点を当てているようです。それは常に「あなたがやろうとしていることに依存する」に要約されるように見えます。しかし、私はよく整理された説明を見ていません：必要な場合はprocを使用するVS必要な場合はステートメントを使用する...
于 2009-05-04T21:40:15.423 に答える
10
ストアド プロシージャの利点:
- 言語間で移植可能
- 間違いなく簡素化されたインターフェイスと、複雑なクエリ、特にマルチクエリ トランザクションのパフォーマンスの向上 (テスト!)
- テーブルではなくインターフェイスを公開することで、セキュリティと整合性を向上させるために使用できます
ストアド プロシージャの欠点:
- ビジネス ロジックをデータベースに入れる - 設計が複雑になり、バージョン管理とトラブルシューティングのために追跡する場所が増える
- 状況によってはパフォーマンスが低下する (テスト!)
- データベース間の移植性が低い
状況によって賛否両論があるため、この質問に対する一般化された単一の答えは存在しないと思います。シンプルさ、DRY、テスト、時期尚早の最適化の回避などの原則に従えば、うまくいく可能性があります。
于 2008-10-13T18:25:30.530 に答える
4
ここで言及するのは当てはまらないか、言及する価値はないかもしれませんが、ストアド プロシージャは、言語に依存しない場合でも "移植可能" です。PHP の場合と同じように、たとえば Java 内からデータベースで同じストアド プロシージャを呼び出すことができます。プロシージャはデータベースに存在するため、データベースにアクセスできるものはすべて同じ方法でクエリを実行できます。
于 2008-10-13T10:14:54.560 に答える
2
まず、私はストアド プロシージャのアイデアが好きではなく、プリペアド ステートメントのルートに行きます。この特定のケースでは、リンゴとオレンジも比較していると思います...どちらも異なる機能を完全に満たすためにそこにあります....
アプリケーションが 95% データベース駆動型である場合にのみ、ストアド プロシージャを検討します。その場合にのみ、データベースにロジックの一部を含めることが理にかなっています。
于 2008-10-14T10:48:51.947 に答える
2
ストアド プロシージャの実質的な利点は、ロジックを適用する前にデータがレイヤー (この場合は PHP/MySQL レイヤー) を越えないことです。一部のクエリでは、複数の select ステートメントが必要になる場合がありますが、これは MySQL 内よりも PHP を介して行う方が遅くなります。
さて、tobyhedeが指摘するように、すべてのロジックを 1 か所にまとめておくとよいでしょう。しかし、PHP を使用して必要なデータをクエリするのが非現実的なプロジェクトに取り組んできました。ストアド プロシージャを使用して実行する必要がありました。
于 2008-10-13T05:27:31.097 に答える
0
PHP には詳しくありませんが、一般的に、ストアド プロシージャは既に "コンパイル" されているため、SQL ステートメントよりもわずかに高速なパフォーマンスが得られる可能性があります。
私の好みは通常、コード管理/展開および単体テストの観点からSQLに固執することです。
于 2008-10-13T03:52:21.897 に答える