PHPとデータベース：ビュー、関数、ストアドプロシージャーパフォーマンス

Question

私はPostgreSQLでPHP Webアプリケーションを開発中です。すべてのSQLクエリはPHPコードから呼び出されています。ビュー、関数、ストアドプロシージャは見ていません。

• カプセル化
• 抽象
• アクセス権（DB管理者に限る）と責任：私が学んだことから、それは彼らが利点でデータベースに格納されているので、これらのデータベース・サブルーチンを使用することは常に良いでしょう
• 避けコンパイル

は、私はあまりにもパフォーマンスの向上についての何かを読んだと思います。私は本当になぜチームがこれをまだ使っていないのか分からない。この特定のケースでは、私は経験から、それらを使用しない理由があることを知りたいと思いますか？

ほとんどの場合、コードに沿ってたくさんの「SELECT」クエリがある場合、Viewsを使用しないのはなぜですか？

私は、コードのリファクタリングを計画しており、DBサーバー上のサブルーチンのコーディングを開始します。私はこれに対して賛成または反対の意見を知りたい。プロジェクトはかなり大きく（多くのテーブル）、多くのデータが格納されることを期待しています。あなたがソーシャルネットワークに持っているデータの量はいくらか増えているので、かなり大きいです。

Answer 1

I.ビューはカプセル化を提供しますが、注意深く設計されていないと、アプリケーションの速度が遅くなる可能性があります。慎重に使用してください。
II。必要に応じて機能を使用します。不要な場合にはそれらを入れる理由はありません。
III。ストアドプロシージャは神聖なもので、どこでも静的なクエリが使用されます！クエリ対ビューに対応して

、ストアドプロシージャのでビューを使用しようとすると、ストアドプロシージャのは最もビューで撮影したパフォーマンスヒットの一部を軽減します。

Answer 2

私の意見では、ビューとストアドプロシージャは通常ほとんど問題なくちょっとした問題です。

私はたくさんの異なるWebアプリケーションを書いていましたが、誰もいないと思います。ストアドプロシージャを持つものは扱いにくいです。アドホックなSQLクエリを持つものは、高速です（SQLインジェクションを避けるプレースホルダやその他のベストプラクティスを使用します）。私のお気に入りのデータベース抽象化（ORM）を使用することで、データベースと直接ではなく、PHPのクラスやオブジェクトを扱うことができます。私はますますそのためのsymfonyフレームワークに目を向けています。

また、一般的にパフォーマンスを早めに最適化しないでください。優れた高速開発のために最適化（ストアドプロシージャなし）。それがうまくいったら、アプリのベンチマークを行い、ボトルネックを見つけて最適化してください。最初から最適化しようとすると時間が無駄になり、複雑さが増します。

Answer 3

は、我々は唯一の大きな利点がある場合、あなたがを述べた機能を使用しようとする「データベース」、彼らはむしろ
「のソースコードよりも、「スキーマの変更」に該当の一部である

変更 "、そして当然のことながらバージョン管理が難しいです。

問題が発生した場合は、差分、ロールバック、および回復できるように、誰が変更したかを完全に把握できるようにしてください。

Answer 4

ストアドプロシージャの利点は、すべての処理がデータベース上で実行されるため、中間結果セットを前後にネットワークシャットインすることがないことです。

不利な点は、そこにある各RDBMSシステムには、ストアドプロシージャの独自の固有の構文があることです。ストアドプロシージャにビジネスロジックを実装することで、アプリケーションを単一のデータベース製品に制限することができます。アプリケーションをデータベースに依存しないようにするには、覚えておく必要があります。また、gahooaが指摘するように、ストアドプロシージャはデータベースに存在するため、開発者としてのアクセスはローカルポリシーによって制限される可能性があります。一部の組織では、DBAにデータベースにアクセスさせるだけです。

@ WolfmanDragon：ビューが本質的に物事を遅くするかどうかはわかりません。ビューの複雑さと使用しているRDBMSに応じて、あなたの走行距離は変わるかもしれません。さらに、RDBMSの中には、一般的に使用されるビューを実体化することができるため、それらのビューへのアクセスが実表と同じくらい高速です。