SQL Serverで異種データの複数のテーブルを結合するためのデータベースモデルリファクタリング？

Question

Webインターフェイスで使用されている科学データのデータベースを再開発する作業を引き継いだ。元の著者は、規模が大きくなくてはるかに難しい「テーブルごとのデータセット」アプローチを採用していた作成された200以上のテーブルを管理できます。私は物事をどう扱うかを理解しようとかなりの時間を費やしましたが、データセットには異種の値が含まれているため、列定義用の設定スキーマを使用してそれらを1つのテーブルに結合することは合理的ではありません。

私はEAV、XML列の可能性を探究し、データベースがSQL Server 2008上で実行されているので、多くのスパース列を持つテーブルを使用しようとしました。DBAは最近作成されたスパース列はバックアップスクリプトで何らかの混乱を招くので、これを行うより良い方法がないかどうかもう一度疑問に思っています。私はEAVがまともなパフォーマンスをもたらさないことを知っています。また、XMLデータ型を使った私の実験でも、一部のテーブルのレコード数が多いため、パフォーマンスが低下することがありました。 、

表のスキーマが一致していないなど、多くのレコードを15,000としていくつかのテーブルが持つ山車や小さな文字列

を含むいくつかの列を持っているほとんどが

• 200周りのテーブル、：

  はここにまとめますカラムは最初の実験データのサンプル数に依存していたためです。

• SQL Server 2008の

私が開発しています新しいバージョンに遺産として、このデータのほとんどを処理することがありますが、私はまだそれを表示し、IT-を照会できるようにする必要があると私は思います現在のマルチテーブルのアプローチと同じように、ストアドプロシージャのテーブル名を動的に指定することで、そうする必要はありません。助言がありますか？

Answer 1

私は最初のステップでは、ビューを通してデータを合理化しようとしていることを示唆しています。同様のデータ・セットをビューを介して論理プールに統合しようとします。

次に、コードをリファクタリングしてビューを見て、Webプラットフォームが効果的に動作するかどうかを確認できます。そこから、ビュー構造が有益かどうかを判断することができます。そうであれば、データを新しいテーブルに物理的に合理化することができます。

この方法でビューを使用する利点は、ビューの索引から少しのパフォーマンスを奪うことができるはずです。また、データに対するより良い処理を提供する必要があります（つまり、新しいバージョンをインストールすると、問題のドメインを完全に理解できることが示唆されます）。

200個のテーブルを単純な生データセットとして使用し、バージョンが引き継ぐと考えているとすれば、最終的なものと同じ名前のビューを書くことができないのか試してみることになるでしょうテーブル名はV2になります。つまり、新しいデータベース構造が実際に動作するかどうかをバックテストすることができます。

最後に、あなたが説明した方法でデータベースを構築したときに、データを見ずに実際に問題を知っているという賢明な言葉。彼らは理由のためにそれをしました。それは悪いデザインであったか、または表面に現れたものが悪いデザインであるという原因があったかのいずれかです。一貫性を問題としています。データを包み込み、一貫性のある方法でデータを作成することができます。

幸運を祈る！