4

SQLサーバーデータベースを使用して.net 3.5で新しいアプリケーションを構築しています。データベースはかなり大きく、データに負荷がかかる約 60 のテーブルがあります。.net アプリケーションには、データ入力およびサードパーティ システムからこのデータベースにデータを取り込む機能があります。

すべてのデータがデータベースで利用可能になった後、システムは多くの計算を行う必要があります。計算ロジックはかなり複雑です。計算に必要なすべてのデータはデータベースにあり、出力もデータベースに保存する必要があります。データ収集は毎週行われ、必要なレポートを生成するには毎週計算を行う必要があります。

上記のシナリオにより、ストアドプロシージャを使用してこれらすべての計算を行うことを考えていました。問題は、データの独立性も必要であり、ストアド プロシージャはそれを提供できないことです。しかし、これを .net by query database で常に行っていると、作業をすぐに終わらせることができないと思います。

たとえば、2000行を返す1つのテーブルをクエリする必要があり、次に各行に対して300の結果を返す別のテーブルをクエリする必要があります。データ、計算を行い、出力を別のテーブルに保存します。

ここで私の質問は、パフォーマンスが重要であるため、ストアド プロシージャ ソリューションを使用してデータベースの独立性を忘れるべきかということです。また、ストアド プロシージャ ソリューションを使用すると、開発時間が大幅に短縮されると思います。クライアントのいずれかがOracleデータベースでこのソリューションを必要とする場合(別のデータベースを維持したくないため)、ストアドプロシージャをOracleデータベースに移植し、将来の変更/機能強化のために2つのバージョンを維持します. 同様に、他のクライアントが他のデータベースを要求する場合があります。

上記の 2000 行は製品 SKU のものです。前述の 300 行は、処理コスト、輸送コストなど、計算したいさまざまな属性のものです。前述の 10 のテーブルには、通貨換算、単位換算、ネットワーク、エリア、会社、販売価格、1 あたりの販売数に関する情報が含まれています。結果のテーブルには、分析とレポートの目的ですべての情報がスター スキーマとして格納されます。目標は、製品に関する詳細な情報を取得して、製品販売のどの属性が費用を負担しているか、どこを改善できるかを知ることです.

4

5 に答える 5

4

データベース以外の場所でデータ操作を行うことは考えていません。

ほとんどの人は、ループ アルゴリズムを使用してデータベース データを処理しようとします。実際の速度が必要な場合は、データを行のセットと考えてください。1 回の更新で数千行を更新できます。初心者のプログラマーが書いた非常に多くのカーソル ループを単一の更新ステートメントに書き直したところ、実行時間が大幅に改善されました。

あなたは言う：

2000行を返す1つのテーブルをクエリする必要があります。次に、各行に対して300の結果を返す別のテーブルをクエリする必要があります。必要なデータを取得するには、複数のテーブル（約10）をクエリする必要があります。

あなたの質問から、結合を使用していないようで、すでにループで考えています。ループするつもりであっても、クエリを作成して必要なすべてのデータを結合し、それをループする方がはるかに優れています。update ステートメントと insert ステートメントには、それらを駆動する非常に複雑なクエリが含まれている可能性があることを覚えておいてください。CASE ステートメント、派生テーブル、条件付き結合 (LEFT OUTER JOIN) を含めると、1 回の更新/挿入でほぼすべての問題を解決できます。

于 2009-02-11T18:48:38.713 に答える
3

これらのテーブルにあるデータの具体的な詳細がなくても、ナプキンの計算の裏側には、提供した例で600万行を超える情報（2,000行* 300行*（1行）の処理について話していることがわかります。 * 10テーブル））。

これらの行はすべて別個のものですか、それともカーディナリティが比較的低い10個のテーブルルックアップ情報ですか？つまり、メモリ内の10個のルックアップテーブルからの情報を含むプログラムを作成し、メモリ内の300行の結果セットを処理して計算を実行することは可能でしょうか。

また、スケーラビリティについても心配します。これをストアドプロシージャで行うと、単一のデータベースサーバーの速度によって制限されるシリアルプロセスであることが保証されます。クライアントプログラムの複数のコピーがあり、それぞれが2,000の初期レコードセットのチャンクを処理する可能性がある場合は、計算の一部を並行して実行できるため、全体的な処理時間が短縮されるだけでなく、次の場合にスケーラブルになります。最初のレコードセットは10倍大きくなります。

于 2009-02-11T07:19:30.400 に答える
1

毎回ストアドプロシージャがありますが、KMがこれらのストアドプロシージャ内で言ったように、これらの反復を最小限に抑えます。つまり、SQLで結合を使用するので、リレーショナルデータベースは結合に非常に優れています。

データベースのスケーラビリティは、特にバッチプロセスでこれらの計算を実行しているように見えるため、小さな問題になります。

最も些細なCRUDアプリケーションを除いて、データベースの独立性は実際には存在しません。したがって、最初の要件がこれをすべてSQL Serverで機能させることである場合は、RDBMSが提供するツールを活用します（すべてのクライアントが多額の費用を費やした後）その上で）。後続のクライアントが本当にSQLServerを使用したくない場合（そしてそれが大きい場合）は、弾丸をかじって、別の種類のストアドプロシージャにコーディングする必要があります。しかし、あなたが特定したように、「クエリデータベースによって.netでこれをすべて行うと、作業をすぐに完了することができないと思います。」必要な場合まで、それを行うための費用を延期しました。

于 2010-02-16T01:56:51.460 に答える
1

計算コードなどのプログラミングは、C# の方が簡単で保守しやすい傾向があります。また、データベースはスケーリングが最も難しいため、通常、SQL Server での処理を最小限に抑えることをお勧めします。

そうは言っても、あなたの説明から、ストアドプロシージャアプローチが道のりのように思えます。計算コードが大量のデータに依存している場合、計算のためにデータをサーバーから移動するとコストが高くなります。したがって、依存データを最適化するための合理的な方法 (ルックアップ テーブルのキャッシュなど) がない限り、ストアド プロシージャを使用しない方がより面倒だと感じる可能性が高くなります。

于 2009-02-11T07:39:14.487 に答える
0

SQL Server Integration Services (SSIS) でこれを行うことを検討します。計算は SSIS に入れますが、クエリはストアド プロシージャのままにしておきます。これにより、データベースの独立性が提供されます。SSIS は、ODBC 接続を使用して任意のデータベースのデータを処理できます。また、高いパフォーマンスも実現します。単純な SELECT ステートメントのみがストアド プロシージャに含まれます。これらは、SQL 標準の一部であり、複数のデータベース製品で同一である可能性が最も高くなります (標準形式のクエリに固執すると仮定すると)。

于 2010-02-16T02:12:56.520 に答える