20

エラーメッセージを見たことがありますか?

-- SQL Server 2000

ビューまたは関数の解決のために補助テーブルを割り当てることができませんでした。
クエリ内のテーブルの最大数 (256) を超えました。

-- SQL Server 2005

クエリ内のテーブル名が多すぎます。許容される最大値は 256 です。

はいの場合、何をしましたか?

あきらめた？顧客の要求を簡素化するよう説得しましたか? データベースを非正規化しましたか?

@(クエリの投稿を希望するすべての人):

  1. 回答編集ウィンドウに 70 キロバイトのコードを貼り付けられるかどうかわかりません。
  2. これができたとしても、この 70 キロバイトのコードは 20 または 30 のビューを参照するため、これは役に立ちません。

ここで自慢しているように聞こえたくありませんが、問題はクエリにありません。クエリは最適 (または少なくともほぼ最適) です。削除できるすべての列とすべてのテーブルを探して、それらを最適化するのに数え切れないほどの時間を費やしました。1 つの SELECT ステートメントで入力する必要がある 200 列または 300 列のレポートを想像してみてください (数年前、まだ小さなレポートであったときに、そのように設計されたためです)。

4

8 に答える 8

9

SQL Server 2005 の場合は、テーブル変数を使用し、データを部分的に構築することをお勧めします。

これを行うには、ユーザーに送信する最終的な結果セットを表すテーブル変数を作成します。

次に、プライマリ テーブル (上記の例の注文テーブルなど) を見つけて、そのデータに加えて、結合が 1 つだけの小さな補足データ (顧客名、製品名) を取得します。SELECT INTO を実行して、これを直接テーブル変数に入れることができます。

そこから、テーブルを反復処理し、行ごとに、結果セットに必要なすべての補足データを取得する一連の小さな SELECT クエリを実行します。これらを各列に挿入します。

完了したら、テーブル変数から単純な SELECT * を実行して、この結果セットをユーザーに返すことができます。

これについて具体的な数値はわかりませんが、これまでに取り組んできた 3 つの異なる例では、これらの小さなクエリを実行した方が、多数の結合を含む 1 つの大規模な選択クエリを実行するよりも実際に高速に動作しました。

于 2008-08-05T15:19:41.187 に答える
1

私はこの種の状況に遭遇したことは一度もありません。正直なところ、クエリで 256 を超えるテーブルを参照するという考えは、私を致命的な恐怖で満たします。

あなたの最初の質問はおそらく「なぜそんなに多いのですか?」であり、その後に「どの情報が必要ではないのですか?」という質問が続くはずです。このようなクエリから返されるデータの量が、アプリケーションのパフォーマンスに深刻な影響を与え始めるのではないかと心配しています。

于 2008-08-05T14:57:40.763 に答える
1

@chopeenこれらの統計を計算する方法を変更し、代わりに製品ごとのすべての統計の別のテーブルを保持することができます。注文が行われると、製品をループし、統計テーブルの適切なレコードを更新します。これにより、レポートの実行時に 1 つの巨大なクエリですべてを実行するのではなく、多くの計算負荷がチェックアウト ページに移動します。もちろん、この方法ではうまくいかない統計もいくつかあります。たとえば、特定の製品を購入した後の顧客の次の購入を追跡する場合などです。

于 2008-08-05T15:19:18.363 に答える
1

これは、SQL Server 2000 で実行されている Dynamics CRM インストールの Reporting Services レポートを作成するときに常に発生します。CRM には適切に正規化されたデータ スキーマがあり、多くの結合が発生します。実際には、制限を 256 からなんと 260 に引き上げるホットフィックスがあります。

Dillie-O が言及しているように、解決策は、適切な「サブ結合」(できれば複数回使用されるもの) を特定し、それらを一時テーブル変数に分解してから、メインの結合で使用することです。これは主要な PIA であり、多くの場合、パフォーマンスが低下します。申し訳ありません。

@ケビン、そのティーが大好きです-それをすべて言います:-)。

于 2008-11-02T15:50:00.493 に答える
0

私はこれと同じ問題を抱えていました...私の開発ボックスはSQLServer2008を実行します（ビューは正常に機能しました）が、本番環境（SQL Server 2005を使用）ではビューは機能しませんでした。エラーをスローしたビューのクエリの一部として新しいビューを使用して、この制限を回避するためにビューを作成することになりました。

論理的な実行を考えるとちょっとばかげているのは同じです...

于 2010-08-19T17:29:08.187 に答える
0

そのクエリを見たいのですが、ある種のイテレータに問題があると思います。可能な状況は考えられませんが、while/case/cursorが悪いか、大量の不十分に実装されたビュー。

于 2008-08-05T14:58:55.270 に答える
0

クエリを投稿してください:D

また、可能性のある問題の 1 つは、1 つのルックアップ テーブルに凝縮できる大量の (200 以上の) 名前/値テーブルを持つ可能性があるように感じます。

于 2008-08-05T15:26:55.027 に答える
0

ビューを作成したいときに、SQL Server 2005 (2008 年に動作) で同じ問題が発生しました。ビューの代わりにストアド プロシージャを作成することで問題を解決しました。

于 2012-03-07T15:59:53.820 に答える