Microsoft AccessでのCTEの代替方法

Question

私は毎日MS Access 2010を使用していますが、共通テーブル式がSQL Serverで使用されているため、パフォーマンスにどのような影響を与えるかについて知りたいと思いますか？

例えば、それはサブクエリを作成した方がよいか、それは本質的に非常に似ている別のクエリからクエリを呼び出すために、より良い..です

例：

SELECT A.field1,A.Date 
FROM (SELECT * FROM TABLE B WHERE B.Date = Restriction) 

または

SELECT A.field1,A.Date 
FROM SavedQueryB 

SavedQueryB：

SELECT * FROM TABLE B WHERE B.Date = Restriction 

複数のクエリを使用すると、デバッグや管理が容易になりますが、データセットが非常に大きい場合はパフォーマンスに影響します。

また、私はVBAでクエリを実装する方法についていくつかのビデオを見てきましたが、まだそれほど快適ではありません。

本質的に。 より効率的でより良い方法は何ですか？より良い習慣に関する提案や勧告はありますか？ ビデオ、書籍、プログラミングの背景（VB.NET）

Answer 1

これは実際にはシナリオのホストがデータ型、結合表、索引などを含む最も効率的な結果を決定するため、コンテキストに依存します。本質的に、掲示されたSELECT statmeentsのような単純なクエリの場合、2つのクエリは同等ですが、Jet/ACE（MS Accessの基本エンジン）クエリオプティマイザは、クエリの構造的必要性に応じて別のプランを再度決定する場合があります。可能であれば、外部問合せをコールすると実行プランにステップが追加されますが、サブクエリは自己完結型の表として実行してからメイン表にリンクできます。各ステップは、仮想テーブルを伴うとして型指定された順序と異なるオペレーションの

リコールSQLの一般的な順序（SQL Serverを参照してください）：

FROM clause  --VT1 
ON clause   --VT2 
WHERE clause  --VT3 
GROUP BY clause --VT4 
HAVING clause  --VT5 
SELECT clause  --VT6 
ORDER BY clause --VT7 

言うことができる何がMS Accessの分析およびキャッシュし、保存されたクエリオブジェクトのためであります最適化された「ベストプラン」バージョン。これは、実行前に後者が最適化されていないVBA文字列クエリに対してストアドクエリを使用するための引数となることがよくあります。さらに、Access 'クエリオブジェクトは他のRDMSのビューオブジェクト（Jet/ACEにはVIEWオブジェクトとPROCEDUREオブジェクトがあります）と同様です。 SQLの世界での定期的な議論では、効率とベストプラクティスという非常に疑問があります。views vs subqueriesと答えは通常「それは依存しています」です。したがって、ニーズに基づいて実験してください。

ここでは、CTEはWITH句（JET/ACEではまだサポートされていません）と表示されている「インラインビュー」と見なされます。 SQLプログラマは、ステートメントの本体で同じステートメントを複数回参照することを避けるため、読みやすさと保守性のためにCTEを使用することがあります。要するに、コーディングの儀式やプロジェクト要件に合ったものを使い、必要に応じて調整します。

リソース

• MS Access 2007 Query Performance Tips- ノートとサブクエリのパフォーマンス上の

• Intermediate Microsoft Jet SQL - ノートとサブクエリ上（ちょうどANY/SOME/ALLについて学んだ）

• Microsoft Jet 3.5 Performance White Paper - ノートとのクエリには

Answer 2

このネストされたサブクラスまたはサブクエリのトピックについては、ここでは議論がありません。基本的に、それらはすべて保存されたクエリを提案し、保存されたクエリを参照します。

個人的な経験から、ネストされたクエリは、後でトラブルシューティングまたは修正することが極めて困難です。また、彼らがあまりにも深くなると、私はパフォーマンスヒットを経験しました。

アレン・ブラウンは、私はアクションクエリの基準にある巣は、多くのことを問い合わせる使用してhere

一つの場所をリストされているいくつかのヒントやトリックを持っています。このようにして私は結合を持たず、 "この操作を実行できません"という問題の一部を制限することができます。

最後に、VBAでクエリ文字列を使用します。私ははるかに簡単にパラメータクエリを構築し、VBAでQueryDefに変数を設定し、VBAでクエリ文字列を構築するのではなく、パラメータを追加することがわかりました。後で問題を解決して修正するのがずっと簡単です。

ちょうど私の2セントです。そのようなあなたの質問のものと最も単純なクエリについては、

Answer 3

、私はあなたがサブクエリと「積み重ねられたクエリ」（そのデータソースとして別の保存されたクエリを使用しています1）のアプローチとの間に有意なパフォーマンスの違いを見ることはないだろう。そして、おそらくdbエンジンは両方に対して同じクエリプランを使用します。 SHOWPLANを使用してクエリプランを調べることができます。

これら2つの例の主なパフォーマンスドライバは、dbエンジンがインデックス付き検索を使用してWHERE制限を満たす行をフェッチできるかどうかです。 TABLE.Dateがインデックス化されていない場合、クエリは、全表スキャンが必要になります。それは非常に大規模なデータセットでひどく吸うだろう、とフルスキャンのパフォーマンスへの影響ははるかにサブクエリと積み重ねられたクエリとの差額を曇らせる必要があります。

状況はAllen Browne explainsのような複雑なサブクエリと異なる可能性があります：

多くのレコードを持つテーブル上の複雑なサブクエリの実行が遅くなることができます。サブクエリのパフォーマンスの問題が発生する可能性修正の中で

は、彼が...ではなく、サブクエリの

使用積み重ねられたクエリを示唆しています。 JETが最初に実行するために別途保存された クエリを作成し、これをメインクエリの の入力 "テーブル"として使用します。この前処理は通常、サブクエリよりも高速ですが（必ずしもそうではありません） です。同様に、1つの クエリで集計を実行し、集計された の結果で動作する別のクエリを作成してください。この後処理は、副問合せを使用して単一の問合せですべてを実行しようとする 問合せよりも数桁高速です。

あなたの最善の答えはより複雑な現実の例をテストすることから来ると思います。あなたの質問の質問は非常に簡単なので、それらから導き出された結論は実際の世界の質問には当てはまりません。