データベースクエリーはどこにあるべきですか？

Question

クエリがデータを必要とするクラスの内部に存在する必要がありますか？クエリをデータベースのストアドプロシージャに保存して、再利用可能にする必要がありますか？

最初の状況では、クエリを変更しても他の人（レポートやその他のコードを生成している人など）には影響しません。第二に、クエリは多くの人によって再利用可能であり、一箇所にしか存在しませんが、誰かがそれらを壊すと、誰もが壊れてしまいます。

Answer 1

以前はデータベースの処理速度が速く、ORMがメインストリームに入っていたので、私は昨年、保存されたprocソリューションに大きな影響を与えました。確かにストアドプロシージャのための場所があります。しかし、単純なCRUD SQLの場合：1つのライナー挿入/更新/選択/削除、これを扱うORMを使用して私の意見で最もエレガントなソリューションですが、多くの人が他の方法を主張すると確信しています。 ORMはSQLとDBの接続をパイプラインから取り除き、永続性ロジックをあなたのアプリケーションとはるかに柔軟に統合します。

Answer 2

データベースにストアドプロシージャとして配置することをお勧めします。再利用の利点があるだけでなく、同じストアドプロシージャを使用しているため同じクエリ（選択、更新、挿入など）が同じであることを確認します。あなたがそれを変更する必要がある場合、あなたは1つの場所でそれを変更するだけです。また、アプリケーションが置かれているサーバー/コンピューターではなく、データベースサーバーの処理能力を活用します。それが私の提案です。

幸運を祈る！

Answer 3

それは状況によって異なります。どちらのオプションに対しても非常に強い議論があります。個人的には、ビジネスロジックがデータベース（ストアドプロシージャ）とコードの間で分割されているのが本当に気に入らないので、通常はすべてのクエリをコード内で可能な限り最大限にしたいと思っています。

Microsoftでは、データベース/ストアドプロシージャの代わりに（およびそれに加えて）クラス/オブジェクトからデータを取得できるReporting Servicesなどがあります。また、Linqのように、より強く型付けされたクエリをコード内で提供するものもあります。 NHibernateのような強力で成熟したORMもあり、コードからのあらゆる種類のクエリを書くことができます。

しかし、ストアドプロシージャではコードよりもはるかにうまく動作するクエリで「行セット」型の処理を行うときがあります。

大部分の状況では、/ bothオプションは正常に機能します。

Answer 4

私の見解では、格納されたprocsが行く方法だと思います。第1に、アプリケーションを再コンパイルしないでスクリプトを実行するだけで簡単に変更できるため、メンテナンスが容易です。第二に、彼らは安全のためにずっと優れています。 spレベルで、テーブルとビューに直接アクセス権を設定することはできません。これにより、ユーザーはストアドプロシージャで指定されていないデータベースに直接何もできないため、不正行為を防ぐことができます。彼らはパフォーマンスチューニングが容易です。ストアドプロシージャを使用する場合は、データベース依存性メタデータを使用して、データベースの変更がコードベースに及ぼす影響を判断できます。多くのシステムでは、すべてのデータアクセスやCRUD操作がアプリケーションを通じて行われるわけではありません。すべてのデータアクセスが1つの場所（私がサポートしているアイデア）にある場合、データベースにアクセスして、それを使用する必要のあるすべてのアプリケーションまたはプロセスからアクセス可能である必要があります。

アプリケーションプログラマーは、バックエンドではなくアプリケーションに焦点を当てているため、データベースが情報を処理する最良の方法を検討しないことがよくあります。データベースのコードを所属するデータベースに入れることで、データベースとその性能を考慮するデータベース専門家が見て、検討する可能性が高くなります。ここでは数百のデータベースとアプリケーションをサポートしています。どのデータベースでも見ることができ、何かが遅いときに見つけなければならないコードを見つけることができます。私は自分の仕事をするために必要な部分を見るために、何百もの異なるアプリケーションのそれぞれにアプリケーションコードをアップロードする必要はありません。