異なるテーブルのデータを1つに集約するのは悪い習慣ですか？
バックグラウンド 私は、大規模なヘルスレコードDBについて多くの大きなレポートを作成し、一般的に管理しています（SP、機能、ジョブなどを作成します）。元のスキーマとそれを使用するソフトウェアは別のベンダーのものであるため、構造についてはあまり変更できません。ラボ、手順、ワクチンなど、追跡を必要とする多くのレコードがあり、それらは多数のテーブルに散らばっています。その多くは肥大化しており、インデックス付けが不十分です（これを多少修正できました）。 問題 問題は、DBをほとんど制御できないため、また特定の更新やパッチから変更される可能性があるため、これらのレポートの作成と保守が困難で面倒になることです（特に重複が多い場合）。必要なのは1つのパッチだけで、多数のレポートの大部分を書き直しています。さらに、結合、ネスト、選択、適用が積み重なると、クエリはすぐに難読化され、遅くなります。 私の「解決策」 私の計画は、これらすべてのレコードを1つの「キャッチオール」テーブルに書き込み、元のテーブルにトリガーを書き込んで、この集約テーブルのレコードを維持することでした。もちろん、更新後にトリガーが完全であることを確認する必要がありますが、保守性の観点から、データを参照するだけの方がはるかに簡単です。 テーブルは薄くて長く、必要なデータのみを保存します。次のようなものです。 CREATE TABLE dbo.HCM_Event_Log ( id INT IDENTITY, type_id INT NULL, orig_id VARCHAR(36) NULL, patient_id UNIQUEIDENTIFIER NOT NULL, visit_id UNIQUEIDENTIFIER NULL, lookup_id VARCHAR(50) NULL, status VARCHAR(15) NULL, ordered_datetime DATETIME NULL, completed_datetime DATETIME NULL, CONSTRAINT PK_HCM_Event_Log PRIMARY KEY CLUSTERED (id) ) 次に、type_idやアイテムのグループ化などのさまざまなリレーショナルテーブルを作成します。 これらのテーブルのいくつかはかなり書き込まれているので、私はこの考えを二番目に推測し始めています。私が書いているSPとレポートはデータも多く参照します。したがって、このテーブルが大量のI / Oを伴うレコードのロックとパフォーマンスの悪夢になることを心配しています。 …