80個のクエリが多すぎますか？

Question

私は大量のデータベースを持っていて、毎週クエリを実行する必要がある何千ものレコードを含んでいます。次に、アクセスレポートを使用してこのデータのサマリーを作成する必要があります。私は最近（私が最近行った）データベースを初めて作成したときに、いくつかの種類のクエリ（約80）を作成し、サブレポートをそれぞれ作成し、これらのサブレポートを1つの巨大なメイン​​レポートに入れました。

これまでにデータベースを使用したことはありませんでした。80種類の異なるサブレポートを作成して80種類のクエリを用意するべきではないことが分かりました。私は知らない、多分それは大丈夫です。しかし、それは私の質問です。私が戻ってこれらの質問のいくつかをやり直し、それらをおそらく20または30（私はサブレポートとメインレポートをやり直す必要があります）に統合する必要がありますか、それともこの多くのクエリをデータベースに保存しておきます。

それぞれのクエリには2つまたは3つの関数しか含まれていませんが、完全に取り除くことができない非常に特殊なタスクがあります。これらの関数をいくつかの型クエリのまた、私が言ったように、私は毎週これらのクエリを使用しなければならないので、私は実際にそれらを実行することを望んでいないいくつかの人々が行うように。

とにかく、私はこの多くの質問をしていないと予期せぬ問題があるのですか？これは正常ですか？

Answer 1

要件が満たされている（「十分に速い」）、他の人を妨害しない（つまり他の誰もが遅くならない）場合は、問題ありません。

すべてのクエリがターゲットデータセットに対して個別にうまく実行されることを確認します。開発時には50行に大きくなる可能性がありますが、本番環境では1M行あります。

しかし、それがあなたのプロダクションDB上であなたのために十分に速く走っていれば、それで終わり、別の問題を解決してください。

これから学習体験を取りたい場合は、直前にロードした道路を修復するのではなく、将来のプロジェクトに適用してください。

Answer 2

すべての詳細を知らなくても、20か80か200の問合せが必要かどうかはわかりません。しかし、より多くのクエリを持つことは何も害を及ぼさず、一般的なデータベースの問題として、より一般的なクエリの数が少なくて済むことではなく、具体的に必要なものにクエリを集中させる方が良いデータは本当に必要以上です。

クエリの数が少なく、追加のデータを表示するためにレポート/クエリを変更する必要がある場合は、同じクエリに依存するすべてのレポートのデータを再テストする必要があります彼らが変更によって壊れていないことを確認してください。

Answer 3

これはレポートの1つです。データベースに80個のクエリを持つことはそれほど悪くはありません。 1つのレポートに対して80件のクエリがある...

パフォーマンスに問題がない場合は、問題が発生していない可能性があります。

これらのクエリの一部は、基本的に同じ列情報を返しますが、結果は異なりますか？その場合は、クエリをリファクタリングしてパラメータを使用する方法を調べてください。

Answer 4

なぜクエリを保存する必要がありますか？多くのレポート/サブレポートがあるかもしれませんが、保存されたクエリとしてSQLを保存する必要はなく、問題のレポートのRecordsourceプロパティとしてSQL SELECTを保存するだけで済みます。

保存されているクエリの数を最小限に抑えるようにしています。必要なものが多くなればなるほど、それを追跡するのが難しくなります。そして、あなたは何が何であるかを知ることができるように何らかの種類の命名規則を考え出す必要があります。そして結局は混乱に終わります。

また、再利用はこれを行う理由ではありません。一般に、オブジェクトを再利用することは良いことですが、保存されたQueryDefの問題は依存関係を簡単にテストすることができません（Name AutoCorrectをオンにすると、クエリの使用場所を確認できます）。したがって、クエリを再利用して、それが使用されている他のコンテキストでクエリを中断する1つのコンテキストの変更を行う場合は、本当に簡単です。したがって、一般的には、関連するデータセットが実際に100％の時間になる場合を除いて、保存されたクエリを再利用しません（フォームと同じデータを提示するレポートなど）。

基本的には、80の保存されたクエリはまともなサイズのアプリではあまり意味がありませんが、あなたが説明したことから、SQLを保存されたクエリにまったく格納する必要はありません。その場合、保存されたZEROクエリは適切な数になります。

Query Design Practices in SQLに関する質問に私の最近の投稿を参照してください。