汎用テーブルを使用して設計された正規化された SQL Server 2008 データベースがあります。そのため、各エンティティ (製品、注文、注文アイテムなど) ごとに個別のテーブルを用意する代わりに、一般的なテーブル (エンティティ、インスタンス、関係、属性など) を使用します。
データをすばやく取得するために、別の非正規化データベースを用意することにしました。これら 2 つのデータベースが異なるスキーマを持っていると仮定して、これら 2 つのデータベースを同期するためのさまざまなテクノロジについて教えてください。
乾杯、モッシュ
2 つのデータベースのスキーマが根本的に異なる場合、同期ではなく、データの移行またはレプリケーションの手法を検討する必要があります。SQL Server は、このために SSIS とレプリケーションの 2 つのテクノロジを提供します。または、これを行う独自のスクリプトを作成することもできます。
レプリケーションは、ソース データベースから新しいデータまたは変更されたデータを取得し、それをターゲット データベースにコピーします。変更のスケジューリング、パッケージ化、配布のメカニズムを提供し、リアルタイム更新とバッチ更新の両方を処理できます。動作させるには、両方のデータベースに十分な情報を追加して、変更と一致する行を追跡する必要があります。あなたの場合、4つ以上の異なるテーブルで関連するすべての変更された行を特定する必要があるため、どの「製品」が変更されたかを特定するのは困難です。可能ですが、多少の努力が必要です。いずれにしても、レプリケーションではソース データの変換が許可されないため、ターゲット スキーマに一致するビューを作成する必要があります。
SSIS は、1 つのソースからデータをプルし、変換して、ターゲットにプッシュします。変更を追跡するための組み込みメカニズムがないため、変更を追跡するにはテーブルにフィールドを追加する必要があります。これは厳密には、スケジュールに従って実行できるバッチ プロセスです。主な利点は、(ビューからのデータの描画を除いて) レプリケーションではほとんど許可されないのに対し、さまざまな変換を実行できることです。製品関連の属性レコードが変更されたときに関連する製品フィールドのみを変更するデータフローを作成するか、単に製品レコード全体を再構成してターゲット レコードを上書きすることができます。
最後に、データが変更されたときに実行される独自のトリガーまたはストアド プロシージャを作成し、あるデータベースから別のデータベースにコピーすることができます。
また、データベースを過度に正規化している可能性があることも指摘しておく必要があります。3 つのケースすべてで、すべてのテーブルを結合してエンティティを再構成すると、パフォーマンスがいくらか低下し、必要なロックが大量に発生し、インデックスの使用が非効率的になります。変更を容易にするために、パフォーマンスとスケーラビリティを犠牲にしています。
おそらく、パフォーマンスとスケーラビリティを維持しながら柔軟なスキーマをサポートする方法について、SQL Server 2008 のスパース カラム機能を検討する必要があります。