18

私は私の別の質問のために受け取った答えの一部を引用しています：

PHP / MySQLの世界では、ストアドプロシージャは使用できません。

知りたいのですが、そうですか？なんで？なぜだめですか？

[編集]これは、特定の必要性を念頭に置いていない一般的な質問として意味します[/編集]

4

10 に答える 10

23

大規模な PHP/MySQL アプリケーションを開発および保守しています。これがストアドプロシージャに関する私の経験です。

時間の経過とともに、アプリケーションは非常に複雑になりました。また、php 側のすべてのロジックを使用すると、100 を超える短いクエリでデータベースにクエリを実行する操作もありました。

MySQL は非常に高速であるため、パフォーマンスは許容範囲内でしたが、優れたものではありませんでした。

最新バージョンのソフトウェアでは、ロジックの一部を複雑な操作のためにストアド プロシージャに移動することを決定しました。

PHP と MySQL の間でデータをやり取りする必要がなかったという事実により、パフォーマンスが大幅に向上しました。

PL/SQL は最新の言語ではなく、デバッグが難しいという点については、他の投稿者の意見に同意します。

結論: ストアド プロシージャは、特定の状況では優れたツールです。ただし、正当な理由がない限り、それらを使用することはお勧めしません。単純なアプリケーションの場合、ストアド プロシージャは手間がかかりません。

于 2008-09-17T15:12:32.533 に答える
10

MySQLでストアドプロシージャを使用する場合、通常のmysqlインターフェイスではなく、PHPのmysqliインターフェイスを使用する必要があることがよくあります。

これは、ストアドプロシージャが複数の結果セットを返すことが多いためです。含まれている場合、mysql APIはそれを処理できず、エラーが発生します。

mysqliインターフェースには、これらの複数の結果セットを処理する関数、mysqli_more_resultsやmysqli_next_resultなどの関数があります。

ストアドプロシージャから結果セットを返す場合は、これらのAPIを使用する必要があることに注意してください。ストアドプロシージャは実際の実行用に1つの結果セットを生成し、その後、から意図的に返された結果セットごとに1つの追加の結果セットを生成します。ストアドプロシージャ。

于 2008-09-17T15:09:03.870 に答える
6

99% の時間で最大のボトルネックとなるデータベースに負荷がかかるため、通常はストアド プロシージャには近づきません。新しい php サーバーを追加することは、MySQL データベースを複製することに比べれば何もありません。

于 2008-09-19T03:23:17.277 に答える
6

それらを考慮に入れる特定の必要性を念頭に置いていますか？ストアド プロシージャは、「プレーンな」SQL よりも移植性がはるかに低くなります。これが、通常、ストアド プロシージャを使用したくない理由です。また、かなりの部分の PL/SQL を書いてきたので、手続き型のコード記述方法は複雑さを増し、あまり現代的でもテスト可能でもないと言わざるを得ません。最適化が必要な特別なケースでは便利かもしれませんが、よく考えてみてください。ジェフも同様の意見を持っています。

于 2008-09-17T13:57:11.733 に答える
2

これは主観的な質問です。

個人的には、すべての計算を PHP 内に含め、実際には MySQL のみをテーブルとして使用します。

しかし、ストアド プロシージャを使用する方が簡単だと感じた場合は、ぜひ実行してください。

于 2008-09-17T13:59:52.177 に答える
1

「ストアド プロシージャはダメだ」とは言いませんが、「正当な理由がなければ使用しないでください」と言うでしょう。

MySQL ストアド プロシージャの構文は特にひどいものであり (Oracle と MSSQL もかなりひどいものです)、それらを維持することはアプリケーションを複雑にするだけです。

本当の (測定可能な) 理由がある場合は、ストアド プロシージャを使用してください。そうでない場合は使用しないでください。とにかくそれが私の意見です。

于 2008-09-17T14:48:05.243 に答える
0

ストアドプロシージャの使用は限られており、うまく機能します。私は会社のクライアントの1人の主任開発者であり、e-commWebサイトで作業しています。クライアントにはストックシステムがあり、システムに一連のストアドプロシージャを実装し、それと通信するためのAPIを構築しました。これにより、データベースを抽象化でき、ストアドプロシージャにロジックを実装できました。シンプルですが、ビジネス要件を非常によく満たしていました。

于 2008-09-17T22:07:21.367 に答える
0

バージョン 5.0 より前の Mysql ではストアド プロシージャがサポートされていないことにも注意してください。http://dev.mysql.com/doc/refman/5.0/en/stored-routines.htmlまた、ストアド プロシージャは、その実装では少し奇妙になる傾向がありました。Mysql 5.1 が普及し始めた今、Mysql でストアド プロシージャがより多く使用されていることがわかります。

于 2008-09-17T21:10:06.840 に答える
0

おそらく、mysql のストアド プロシージャに対する恐怖症が存在する可能性があります。その理由の 1 つは、圧倒的に強力ではないことです (Postgresql や MSSQL に比べて、mysql のストアド プロシージャは大幅に不足しています)。

プラス面: 複数の言語から簡単にインターフェースできるようになります。

誰かが「ストアド プロシージャを使用するのは良くない。別のデータベースに移植できないから」と述べた場合、これはもちろん、データベースを切り替える可能性が高いと考えていることを意味します。

最近はORMを使うのが流行っていますが、個人的にはORMは悪いことだと思っています (質問:82882 )

于 2008-09-17T13:58:41.743 に答える
0

同じSQLコードチャンクを使用して同じデータを更新または追加する場合と同様に、ストアドプロシージャを使用すると、特定のアプリケーションで抽象化を提供できると思います.1つのsproc save_user($attr..... ）むしろ、あちこちで自分自身を繰り返すのではなく.

構文が毛むくじゃらであることに同意し、MSSQL と oracle sprocs に慣れている場合は、イライラする可能性のある違いがあります。

于 2008-09-17T15:24:33.487 に答える