php/mysql の世界ではストアド プロシージャは禁止ですか?
https://stackoverflow.com/questions/83419
-
01-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
いただいた回答の一部を引用します 私のもう一つの質問:
PHP/mysqlの世界では、ストアドプロシージャはノーゴーだと思います
私が知りたいのですが：そうですか？なぜ？なぜだめですか？
[編集]これは、特定の必要性を念頭に置いていない一般的な質問として意味しています[/編集]
解決
私は大規模な PHP/MySQL アプリケーションを開発および保守しています。これがストアドプロシージャに関する私の経験です。
時間の経過とともに、アプリケーションは非常に複雑になってきました。また、PHP 側のすべてのロジックを使用すると、一部の操作では 100 を超える短いクエリでデータベースをクエリすることになります。
MySQL は非常に高速なので、パフォーマンスはまだ許容範囲内ですが、素晴らしいものではありませんでした。
ソフトウェアの最新バージョンでは、複雑な操作のためにロジックの一部をストアド プロシージャに移動することを決定しました。
PHP と MySQL の間でデータを送受信する必要がなくなったため、パフォーマンスが大幅に向上しました。
PL/SQL は最新の言語ではなく、デバッグが難しいという他の投稿者の意見に私も同意します。
結論:ストアド プロシージャは、特定の状況では優れたツールです。ただし、特別な理由がない限り、これらを使用することはお勧めしません。単純なアプリケーションの場合、ストアド プロシージャは手間をかける価値がありません。
他のヒント
MySQL でストアド プロシージャを使用する場合、多くの場合、 ミスクリ 通常のインターフェイスではなく、PHP のインターフェイス mysql インターフェース。
この理由は、ストアド プロシージャが複数の結果セットを返すことが多いためです。そうなった場合、mysql API はそれを処理できず、エラーが発生します。
mysqli インターフェースには、これらの複数の結果セットを処理するための関数、次のような関数があります。 mysqli_more_results そして mysqli_next_result.
ストアド プロシージャから結果セットを返す場合は、これらの API を使用する必要があることに注意してください。ストアド プロシージャは、実際の実行に対して 1 つの結果セットを生成し、次に意図的に返された結果セットごとに 1 つの追加の結果セットを生成するためです。ストアド プロシージャ。
ストアド プロシージャは、99% の場合、最大のボトルネックとなるデータベースに負荷を加えるため、私は通常、ストアド プロシージャには近づきません。新しい PHP サーバーを追加することは、MySQL データベースをレプリケートすることに比べれば何もありません。
それらを検討するに足る具体的なニーズはありますか?ストアド プロシージャは「単純な」SQL よりも移植性がはるかに低いため、通常はストアド プロシージャを使用したくないのです。また、PL/SQL のかなりの部分を書いてきた私は、コードを記述する手続き型の方法が複雑さを増し、あまり現代的ではなく、テストしにくいと言わざるを得ません。最適化が必要な特殊なケースでは便利かもしれませんが、よく考えてください。ジェフは 同様の意見.
これは主観的な質問です。
私は個人的にはすべての計算を PHP 内に組み込み、MySQL をテーブルとしてのみ使用します。
ただし、ストアド プロシージャを使用する方が簡単だと思われる場合は、ぜひストアド プロシージャを使用してください。
私は「ストアド プロシージャはダメだ」とは言いませんが、「正当な理由がなければストアド プロシージャを使用しないでください」と言います。
MySQL ストアド プロシージャの構文は特にひどい (Oracle と MSSQL もかなりひどい) ため、それらを維持するとアプリケーションが複雑になるだけです。
実際に (測定可能な) 理由がある場合はストアド プロシージャを使用し、そうでない場合は使用しないでください。とにかくそれが私の意見です。
mysql のストアド プロシージャに対する嫌悪感があるのかもしれません。これは、圧倒的に強力ではないことも原因の 1 つです (Postgresql や MSSQL と比較しても、mysql ストアド プロシージャは大幅に不足しています)。
プラス面:これらにより、複数の言語からのインターフェースが簡単になります。
誰かがこう言ったら」ストアド プロシージャの使用は、別のデータベースに移植できないため良くありません。「これはもちろん、あなたがデータベースを切り替える可能性が高いと彼らが考えていることを意味します。つまり、彼らはあなたが mysql を使用すべきではないと考えていると言っていることになります。
最近 ORM を使用するのが人気ですが、個人的には ORM は悪いものだと考えています (質問:82882)
ストアド プロシージャを使用すると、特定のアプリケーションで抽象化を実現できると思います。同じ SQL コード チャンクを使用して同じデータを更新または追加する場合は、1 つの sproc save_user($attr....) を作成できます。 ）あちこちで同じことを繰り返すのではありません。
構文が複雑であることに同意します。MSSQL と Oracle sproc に慣れている場合は、戸惑う可能性のある相違点があります。
また、バージョン 5.0 より前の Mysql ではストアド プロシージャがサポートされていなかったことにも注意する必要があります。 http://dev.mysql.com/doc/refman/5.0/en/stored-routines.html また、その実装ではストアド プロシージャが少し奇妙になる傾向がありました。現在、Mysql 5.1 が世に出始めており、Mysql でストアド プロシージャの使用が増えています。
私はストアド プロシージャを限定的に使用していますが、うまく機能します。私はクライアント企業の開発責任者として、電子通信 Web サイトの開発に取り組んでいます。クライアントはストック システムを持っており、私たちはそのシステムに一連のストアド プロシージャを実装し、それと通信するための API を構築しました。これにより、データベースを抽象化し、ストアド プロシージャにロジックを実装できるようになりました。シンプルですが、ビジネス要件を非常によく満たしていました。
