1

SQL Server 2005 に関する本を何冊か読みましたが、探しているものに対する適切な答えが見つかりませんでした。

問題は次のようなものです:- 顧客の注文を予約するために、一度に 5 ～ 20 人のユーザーが使用するデータベースがあります。彼らは電話で 1 日に多くの注文を受けるため、注文の発注と製品の検索、または古い注文を迅速に行う必要があります。

時間の経過とともに多くの注文が寄せられました。この注文の詳細を含む多くのテーブルがあり、このデータを使用する多くのレポートがあります。問題は、レポートが非常に遅いことです。インデックス作成は少し役に立ちましたが、期待したほどではありませんでした。

少し読んだ後、データベースを 2 つに分割してみます。1 つはオンライン トランザクション用で、もう 1 つはレポート専用です。

迅速な報告のためのデータベースの設計方法と、2 つのデータベース (1 つはオンライン トランザクション用、もう 1 つは迅速な報告用) を分離する方法を教えてくれる本やサイトを提案してくれれば、非常にありがたいです (これは迅速なレポートのためのデータ ウェアハウスの設計でしょうか?)

私の主な目標は、非常に高速なレポートを作成することです (一部のレポートは実行に 5 分かかり、データが増えると遅くなります)。私を正しい方向に向ける助けがあれば、深く感謝します。

4

2 に答える 2

2

RalphKimballのDataWarehouseToolkitを見てください。単なるスタースキーマでレポートを高速化できる場合があります。そして、スタースキーマがレポートを簡素化する方法の例を次に示します。

于 2009-12-03T19:38:16.113 に答える
2

まず、既存の設計とワークロードを確認してください。

OLTP 側をこれ以上最適化できない場合は、完全に Kimball データ ウェアハウスの方法論に行きます。SSIS などを使用して通常のデータベースでデータを更新し、データをスターに変換します。レポートのパフォーマンスが大幅に向上し、OLTP/正規化された側で本番トランザクションを妨げないことがわかるはずです。

これにより、レポーティングにはあまり適していない正規化されたデータベース スキーマに関するレポーティングによって以前は消費されていた予備のサイクルを使用して、2 つのデータベースを非常に緊密に同期させることさえできるようになります。トリガーまたはスケジュールされたタスクを使用して、ウェアハウスを比較的簡単に最新の状態に保つことができます。スケールアップすると、より複雑なオプションが利用可能になります。

データベースがそれほど大きくない場合、これは必ずしも 2 つのデータベースにある必要はありません。別のスキーマを使用してそれらを論理的に整理することができます。分割した場合でも、OLTP データベースにビューを配置してそれらを作成できます。接続のデータベースを変更せずに利用できます。別のデータベースを持つ主な利点は、照合順序やバックアップ モデルなど、データベース全体のオプションを変更できることです (もちろん、ファイル グループを使用してそれを支援することもできます)。

于 2009-12-03T22:05:46.123 に答える