4

1,000 万行、5 GB のデータ、主キーなしの DB テーブルがありますが、クラスター化されたインデックスがあります。毎日、何十万ものレコードが追加されます。新しい列を追加しようとしています：

 ALTER TABLE dbo.CMS_hsplit ADD
     split_locIDacd  AS CONVERT(varchar(8), split) + '-' + 
     CONVERT(varchar(8), CASE WHEN loc_id = 105 THEN acd ELSE loc_id END) PERSISTED

これに割り当てられた DBA は、代わりにテーブルをロードする ETL プロセスを変更することを好みます。永続化された計算フィールドがデータを埋め戻すのに時間がかかることはわかっています。計算フィールドの使用に関連する大きなオーバーヘッドは本当にありますか?

アップデート

計算フィールドは何年も変更されないことが予想されます

定義が変更された場合、遡及的でなければならない

4

1 に答える 1

7

列を追加または設定するオーバーヘッドは、実際には問題ではないと思います。さらに重要な問題は、計算列の定義が、データベースの存続期間中、テーブル内のすべての行に対して常に有効であるかということです。定義を変更する必要がある場合、または特定の日付以降に追加された新しい行の定義は異なるが、古い行は現在の行を保持する必要がある場合、計算列は実用的ではないか、まったく不可能です。

私の好みは、通常の列を追加し、それを ETL プロセスに入力するためのビジネス ルールを追加することです。これにより、すべてのビジネス ルールがコードとスキーマに分割されるのではなく、1 か所 (ETL コード) にまとめられます。

于 2012-12-20T19:46:16.717 に答える