3

私のウェアハウス データマート データは、同じサーバー上の 3 つのデータベースに分割されています。これは、個々のデータベースにロードされた 3 つの抽出物を含む概念実証プロジェクトです。

立方体に引っ張っている間、私は基本的にこれをやっています：

SELECT * FROM DB1.dbo.Fact_Pres
UNION
SELECT * FROM DB2.dbo.Fact_Pres
UNION
SELECT * FROM DB3.dbo.Fact_Pres

実際にデータを 1 つのテーブルに統合する必要がありますか? それによって処理が速くなりますか?

ディスク容量に問題はありません。最適なソリューションを実装したいと考えています。

どちらの場合でも、あなたが提案する方法が最適である理由を理解するのを手伝ってもらえますか?

4

4 に答える 4

3

はい、間違いなくそうすべきです。同じテーブルを異なるデータベースに分割しても意味がありません。ハードディスク容量に問題がある場合は、テーブルを分割することを検討してください。

あなたのコメントについて：

パフォーマンス コストはそれほど大きくありませんが、ユニオンはマージ結合を実行するため、オーバーヘッドが少しかかります。

それに加えて、UNION を正しく使用していますか? UNION は、重複する値を排除します。たぶん、あなたが本当にやりたいのはUNION ALLですか？

于 2009-12-01T13:21:42.747 に答える
3

(自分で行うのではなく) SQL Server のファースト クラス パーティショニングを使用してテーブルを統合することを検討してください。常にすべてのデータ ポイントを選択している場合は、複数のディスクを使用する方が高速です。

しかし、なぜ複数のデータベースがあるのでしょうか? 常に 3 つのテーブルを 1 つのテーブルに積み重ねることができますが、その 1 つのテーブルを一緒に RAID された 3 つのドライブの上に実装します。あなたが求めているのがスピードである場合、これはより明確な解決策です。

フェデレーションは、セットの特定の隣接する部分を選択する場合にのみ意味があります。しかし、OPによると、すべてを選択しているため、その利点がなくなります。

于 2009-12-01T13:45:18.833 に答える
2

データベース間クエリは、データベース内よりも（やや）低速です。3つの個別のテーブルが必要な場合は、同じデータベース内で異なるスキーマを使用することをお勧めします。これがたまたま1つのファクトテーブルである場合、サイズが大きすぎる場合は、単一のファクトテーブルにロードし、パーティショニングを使用するのが最善です。

ETLに関しては、ETLを同じDB内の別のスキーマ（ETLなど）のステージングテーブルに入れ、そこからファクトテーブルをロードすることをお勧めします。完了したら、ステージングテーブルを切り捨てます。

The recommendations are from the Microsoft Project Real.

Also keep in mind that foreign key can not be used across databases.

于 2009-12-01T14:03:45.277 に答える
1

UNIONは本質的に a を実行して、重複select distinctレコードを削除できるようにします。これにより、(潜在的に) パフォーマンスが低下します。に変更することで修正できUNION ALLます。

さらに、実行計画をチェックして、どのようなパフォーマンス ヒットが得られているかを確認する必要があります。SQL Server が他のデータベースのテーブルでもインデックスを使用することは知っていますが、ここで行っていることはまだあまり意味がありません。通常の使用シナリオがUNIONすべてのテーブルをまとめて使用する場合は、テーブルのパーティション分割を使用してすべてを 1 つのデータベースに保持することをお勧めします。それらを異なるデータベースに分離する正当な理由はほとんどありません。

于 2009-12-01T13:55:44.670 に答える