【考察】php+mysqlでストアドプロシージャを使うメリットとデメリットについて話しましょう

いくつかのオープンソース システムを見たことがありますが、ストアド プロシージャを使用したことはありません。
PHP プロジェクトでストアド プロシージャを使用する必要がありますか?手順を実行すると、速度が向上し、Web サーバーの負荷が軽減されるはずです
同時に、データベース サーバーの負荷も増加します
より経験豊富な学生と話し合ってみましょう
一緒に議論しましょう。

ディスカッションへの返信（解決策）

基本的に、小規模なデータベース操作を行う必要はないはずです

頻繁かつ複雑な使用により、効率を大幅に向上できるはずです

これには誰も興味がありません -。 -

この機能があるので、それを使用しましょう。唯一の説明は、SQL ステートメントを繰り返し書かないようにすることです。

この機能は実際にはあまり便利ではないので、SQL ステートメントを繰り返し書かないようにするための唯一の説明です。

-。 - あまり役に立たないのはなぜですか?

セキュリティを含め、いくつかの点で非常に役立ちます

毎回解析してコンパイルする必要がありません

。この機能があるので、実際にはあまり役に立ちません。SQL ステートメントを繰り返し書かないようにするための唯一の説明です。
ご意見をお聞かせいただきありがとうございます。

通りすがりの兄弟や後輩、先輩専門家など

本当はもっと専門的な分析が聞きたいです
ありがとうございます

パフォーマンスは少し痛いです！

パフォーマンスに少しダメージを与えます!
それはパフォーマンスの向上です-。 -

私はいくつかのオープンソースシステムを見たことがありますが、ストアドプロシージャを使用したことはありません。それらはすべて SQL で 1 つずつ実行されます

すべてのデータベースがストアド プロシージャをサポートしているわけではありません。たとえば、mysql4 はサポートしていません
また、データベースが異なれば構文も異なります。

PHP プロジェクトでストアド プロシージャを使用する必要がありますか?

可能であれば、ストアド プロシージャを使用すると、速度が向上し、負荷が軽減されます。 Webサーバー

これは避けられません

しかし、同時にデータベースサーバーの負荷も増加します 個人的な理解

この理解は間違っています。データベースサーバー?


私が取り組んできたプロジェクトは常にストアド プロシージャを使用してきました

比較的メンテナンスが便利です

mysql でストアド プロシージャを使用したことはありません。

memcache と静的ページでは、ストアド プロシージャは役に立たなくなりました

ストアド プロシージャは悪くありませんが、特に動的スクリプトは変更後にデータベースをインポートする必要があり、時間の無駄です。

それ以外の場合は、今では誰もがストアド プロシージャを作成し、SQL クエリ ステートメントを作成しなくなりました。

私はいくつかのオープンソースシステムを見てきましたが、ストアドプロシージャを使用したことはありません。それらはすべて SQL で 1 つずつ実行されます

すべてのデータベースがストアドプロシージャをサポートしているわけではありません。たとえば、mysql4 はサポートしていません
また、データベースが異なれば、ストアドプロシージャの構文も異なります。
PHP プロジェクトでストアド プロシージャを使用する必要がありますか?
ストアド プロシージャを使用すると、アルゴリズムの効率が大幅に向上します。

ストアド プロシージャを使用すると、速度が向上し、Web サーバーへの負荷が軽減されます。は避けられません

しかし、同時に数も増えます...
それらにはすべてオーバーヘッドがありますが、それぞれ異なります:
機能的には、PHP の組み込み関数と外部関数の違いに似ています。
使用法は、コンパイル済み関数とコンパイル済み関数の違いに似ています。言語と通訳言語。
特にアジャイル開発の時代では、ストアド プロシージャのパフォーマンスを向上させるために、
一度変更してコンパイルすると、これらのオーバーヘッドについてどこから話し始めればよいのかわかりません。
上の階の人たちからの回答ありがとうございます

memcacheと静的ページでは、ストアドプロシージャは役に立ちません

ストアドプロシージャは悪くありませんが、特に動的スクリプトを変更すると、面倒になります。データベースを再度インポートしてください。それは単なる愚かな用事です
それ以外の場合は、SQL クエリ ステートメントの代わりにストアド プロシージャを作成することになります。
up++
私が作成したストアド プロシージャは phpmyadmin にインポートできません。インポートするには mysql_query を実行する必要があります。消去します。

通りすがりの兄弟や後輩、先輩専門家など
ぜひ、もっと専門的な分析を聞きたいです
同時に、データベースサーバーの負荷も増加しています

zy205817さんの返信より引用。 7 階:
パフォーマンスに少しダメージがあります!
それはパフォーマンスの向上です-。 - その後、すべての操作のストアド プロシージャを作成するだけです。メリットとデメリットがあります！

ストアドプロシージャの話をすると、卒業時にインターンシップの会社を探していたことを思い出します。そのような会社があり、面接の監督はとても美人でした。しかし、彼女が尋ねた質問は、ストアド プロシージャのログイン モジュールを作成することでした。なので、少し抵抗がありました。 ^_^.
ただし、そうは言っても、負荷が高く同時実行性の高い Web サイトでは、通常、マスター/スレーブ、LVS、ミドルウェア、垂直サブライブラリ、水平サブテーブルを使用する必要があります。
nosql の一般的な使用、つまり非リレーショナル データベースの使用は、通常、大規模な Web サイトで使用されます。 Redisを推奨します。

8階kxn308さんの返信より引用：
7階zy205817さんの返信より引用：
パフォーマンスに少しダメージがあります！
それはパフォーマンスの向上です-。 -
次に、すべての操作のストアド プロシージャを作成するだけです。メリットとデメリットがあります！
プロジェクトの結合の長所と短所
一部の単純なものはもちろん必要ありません
パフォーマンスはさらに向上します

まず第一に、プロジェクトのデータベースの操作が複雑かどうか、および開発者がデータベース プログラミングについて深いかどうかによって異なります
ストアド プロシージャ自体はパフォーマンスを向上させますが、単純なプロジェクトには過剰であるだけです
また、ストアド プロシージャの利点を利用してトランザクションをカプセル化することもできます。 もちろん、これは複雑な操作も前提としています

ストアド プロシージャの話をすると、卒業時にインターンシップユニットを探しているのですが、面接してくれた上司がとても美人でした。しかし、彼女が尋ねた質問は、ストアド プロシージャのログイン モジュールを作成することでした。なので、少し抵抗がありました。 ^_^.
ただし、そうは言っても、負荷が高く同時実行性の高い Web サイトでは、通常、マスター/スレーブ、LVS、ミドルウェア、垂直サブライブラリ、水平サブテーブルを使用する必要があります。
nosql の一般的な使用、つまり非リレーショナル データベースの使用は、一般に大規模な Web サイトで使用されます。 Redisを推奨します。
ストアド プロシージャは SQL コンパイルの効率を向上させる一方で、複雑なビジネス ロジックをここで処理できます。
あなたが言及したことはすべて、高負荷および高同時実行条件下でパフォーマンスの問題を解決する方法に関するものですが、複雑なビジネス ロジックの処理の問題を解決することはできません。
Redis の勉強に時間を費やしました。複雑なビジネス ロジックを扱うのは難しいです。

ストアド プロシージャはサーバー全体のパフォーマンスを向上させることができますか?
たとえば、PHP と MySQL が異なるサーバーにデプロイされている場合、PHP が 1 つずつ実行されると、多くのサーバー間呼び出しが発生し、ネットワーク遅延が比較的大きくなりますが、ストアド プロシージャが使用される場合、PHP は一度呼ばれます。