1

いくつかの列と、varbinaryである2つの最後の（null許容）列を含むテーブルがあります（実際には、これらはSQL 2008の地理タイプですが、このポストデータベースに依存しないようにします）。

私は約200K行で約500mbをヒットしました。varbinaryが問題です-そして私はデータが必要です。

だから、私が次のことをすると悪いのではないかと思っていました：-

  • 別のファイルグループを作成します：SpatialData.mdf
  • その新しいファイルグループに割り当てられた新しいテーブルを作成します。
  • すべての空間データ（読み取り：最後の2つのフィールド）を元のテーブルから新しいテーブルに移動します。新しいテーブルには、元のテーブルに対する外部キーがあります。
  • 両方のテーブルを表すビューを作成します。

これで、関係が次のようになるため、ビューは左外部結合になります。新しいテーブルは、元のテーブルに対して0行または1行の関係になります。

例えば。

元のテーブル

FooId INT PK NOT NULL IDENTITY
Blah VARCHAR(..) NOT NULL
Boo WHATEVER NOT NULL

新しいテーブル

FooID PK FK NOT NULL
Spatial_A VARBINARY(MAX)/GEOGRAPHY
Spatial_B VARBINARY(MAX)/GEOGRAPHY

これが悪いかどうかを知りたい理由は、ビューと、ビューが空間テーブルでどのように結合を行っているかによるものです。ビューをよく使用します。現在、元のテーブルに対してクエリを実行しています（新しいテーブルがまだ存在しないため）。この結合とPK/FK関係を追加することにより、これはパフォーマンスに影響しますか？

なぜデータを分割するのですか？ライブDBを開発サーバーに時々ダウンロードする必要があります。これらの2つの空間フィールドについてはあまり気にしないので、それらがないことは問題ありません。そのため、ダウンロードするデータベースのサイズははるかに小さくなります。

考え？

4

2 に答える 2

1

2番目のテーブルを作成し、結合してビューを作成する代わりに、SQL Server 2005/2008で可能なより良いソリューションは、テーブルのパーティション分割を使用することです。私の記憶では、テーブルを垂直に分割し、いくつかの列（つまり地理空間列）を1つのファイルグループに配置し、残りを別のファイルグループに配置することができます。SQL Serverが残りを処理します。結合を気にする必要はなく、ビューも必要ありません。

于 2009-05-28T00:03:32.977 に答える
1

あなたが説明した方法は、私の経験では実際にはかなり一般的です。技術的には、データベースを最大限に正規化する場合、正規化の (通常は使用されない) ステップの 1 つに NULL 値を持つ列がないことを確認することが含まれているため、そのようなテーブルが多数存在することになります。

実際には、通常、その程度まで実行されることはありませんが、データがまばらに存在する列 (または複数の列) については、それを分離することは悪い考えではありません。テーブルが同じ主キー (もちろんインデックスが作成されます) を共有している限り、パフォーマンスは問題になりません。

于 2009-05-28T02:30:15.630 に答える