DateTimeからDateTimeOffsetへの移行

システムをある状態から別の状態に変換したいと想像してください。 初期状態は、DateTimeがC＃コードとデータベースでどこでも使用されるときです。 最終状態は、DateTimeOffsetがどこでも使用されるときです。 移行をスムーズに行い、できるだけ少ない変更を加えたいと考えています。 この説明は、最後に行き止まりの非常に興味深いタスクの始まりかもしれません。



DateTime型は、少し前の日付と時刻を操作するためのデフォルトの.NET型であり、通常、その周りに構築されたロジックは、変更されないように作成されました。 タイプを1ステップで変更しようとすると、システムのほぼすべての部分でカスケード変更が発生します。 極端な場合、1つのフィールドのみで約200のストアドプロシージャを変更する必要があります。 これが最初の問題です。 2番目の問題は、テスト中にそのような変更の結果を見つけるのが難しいことです。 回帰テストでは、何かを見逃さないことや、システムが機能することを保証しません。 作業するにつれて必要な品質保証の努力が増し、いつ終了するのか明確に理解できなくなります。



私の研究中に、私はそのような変換への可能なアプローチを見つけました。 このアプローチには3つの段階があり、システムが現在タイムゾーンをサポートしておらず、すべてのサブシステムが同じタイムゾーンにあるという仮定に基づいています。

1. ペアの計算フィールドを追加して、データベースからDateTimeOffset値を読み取ります。
2. 読み取り操作の変換を行います。
3. 書き込み操作の変換を行います。

このアプローチは、変更をローカライズし、QAの努力を制限するのに役立ちます。 また、将来の作業を評価するための優れた予測可能性も提供します。 以下に手順を詳細に説明します。

悪いアプローチ

日付/時刻の値に関連付けられた約150のフィールドがあるとします。 次のSQLスクリプトを使用して、データベース内の完全なリストを見つけることができます。

select tbl.name as 'table', col.name as 'column', tp.name as 'type', def.name as 'default' from sys.columns col inner join sys.tables tbl on tbl.[object_id] = col.[object_id] inner join sys.types tp on tp.system_type_id = col.system_type_id and tp.name in ('datetime', 'date', 'time', 'datetime2', 'datetimeoffset', 'smalldatetime') left join sys.default_constraints def on def.parent_object_id = col.[object_id] and def.parent_column_id = col.column_id order by tbl.name, col.name
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データベースでは、DateTimeからDateTimeOffsetへの変換、およびその逆の変換が非常に優れたレベルでサポートされていますが、C＃コードでは、入力のためにこれは困難です。 データベースがDateTimeOffset値を返す場合、DateTime値を読み取ることはできません。 1つのフィールドの戻り値の型を変更する場合、システム全体で使用されるすべての場所を変更する必要があります。 場合によっては、システムが非常に大きい場合は一部の場所を知らない可能性があるため、これは単に不可能です。 このため、単純なフィールドタイプの変更を伴うアプローチは機能しません。 次のスクリプトを使用して、データベース内の特定のテーブルフィールドのすべての使用を見つけることができます。

 SELECT ROUTINE_NAME, ROUTINE_DEFINITION FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_DEFINITION LIKE '%table%' OR ROUTINE_DEFINITION LIKE '%field%' AND ROUTINE_TYPE='PROCEDURE'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

変換を行うには、システムのどの部分が影響を受けるかを事前に予測することが重要です。 残りの部分に違反することなく、システムの特定のモジュールの変更をローカライズするアプローチが必要です。

より良いアプローチ

このアプローチは単に「より良い」ものであり、最良の方法ではありません。 将来、いくつかの問題が発生することを期待していますが、以前の問題よりも安全に見えます。 主な違いは、1ステップで変換を実行しないことです。 状況の制御を可能にする一連の従属変更があります。

計算フィールドの作成

計算された重複フィールドをデータベースに追加する場合、必要なタイプの新しいフィールドを入力します。 これにより、読み取り、書き込み、更新されたコードを古いコードから分離できます。 この操作はスクリプトを使用して簡単に実行でき、品質保証の努力は必要ありません。

 declare @table sysname, @column sysname, @type sysname, @default sysname declare cols cursor for select tbl.name as 'table', col.name as 'column', tp.name as 'type', def.name as 'default' from sys.columns col inner join sys.tables tbl on tbl.[object_id] = col.[object_id] inner join sys.types tp on tp.system_type_id = col.system_type_id and tp.name in ('datetime', 'date', 'time', 'datetime2', 'smalldatetime') left join sys.default_constraints def on def.parent_object_id = col.[object_id] and def.parent_column_id = col.column_id order by tbl.name, col.name open cols fetch from cols into @table, @column, @type, @default while @@FETCH_STATUS = 0 begin declare @cmd nvarchar(max) set @cmd = 'alter table ['+@table+'] add ['+@column+'_dto] as todatetimeoffset(['+@column+'], ''+00:00'')' exec (@cmd) fetch from cols into @table, @column, @type, @default end close cols deallocate cols
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記の結果に基づいて、DateTimeOffsetを入力するセクションにシステムをスライスできます。 これで、関連するすべての場所を変更することなく、1つのストアドプロシージャでのみ新しい型を使用できます。

読書変換

読み取り操作は、クライアントコードとデータベース間の統合に使用されるアプローチのため、変換が最も困難であることが判明しました。 日付/時刻の値は、文字列のシリアル化を通じて渡されます。 DateTimeOffsetの形式は異なり、クライアント側のDateTime変数ではデフォルトで読み取ることができません。 同時に、書き込み操作は機能します。 DateTime値を引数またはDateTimeOffsetフィールドに渡すと、その値はUTCに調整されているという前提で受け入れられます。 変換後の時間オフセットは「+00：00」になります。



これで、システムの一部を取り出して、クライアントコードでDateTimeを返すストレージの正確な数を特定できます。 ここでは、DateTimeOffset値を読み取るために、C＃コードの読み取り操作を変更する必要があります。 また、データベースのストレージ自体を変更して、新しい計算フィールドから値を返すようにする必要があります。 このステップで期待される結果は次のとおりです。

• C＃コードはDateTimeOffsetを読み取り、可能な限りシステムから値を返すためにこの型を使用します。
• データベースストレージは引数でDateTimeOffsetを使用し、C＃コードはDateTimeOffsetをそれらに渡します。
• 新しいタイプはデータベース内で使用されます。
• データベースストレージは、新しく追加されたフィールドから値を返します。

その結果、新しいフィールドからデータを読み取り、古いフィールドに値を保存するシステムが得られます。 これで、記録操作でタイムオフセットが転送され、システムに保存されるとすぐに、システム全体がタイムゾーンで正しく動作し始めます。

変換レコード

ここで、システムの時間オフセットを修正し、データベースに送信して、フィールドに保存する必要があります。 古いフィールドを取得して、新しいフィールドから計算フィールドに変更する必要があり、新しいフィールドには値が含まれるようになります。 すでにそれらを読んでいますが、今では値も書き留めています。そして、古いものは逆に、ただ読んでいます。 このアプローチは、特定のセクションの変更のみを分離するのに役立ちます。 予想される結果は次のとおりです。

• C＃コードはDateTimeOffset値を作成し、データベースに渡します
• 新しいフィールドは値を持つ実フィールドになりました
• 古いフィールドが計算され、読み取りに使用されるようになりました。
• データベースストレージは、新しいフィールドに値を保存します

最終的に、新しいDateTimeOffset型を読み書きするシステムになります。 このタイプには、タイムオフセットのサポートが組み込まれているため、通常、UTCまたはタイムゾーン間で手動で変換する必要はありません。

さらなるステップ

システムを変換用のセクションに分割することに関して私ができる唯一の推奨事項は次のとおりです。使用するストレージに応じてモジュールを十分に分離する必要があります。 したがって、努力の予測可能性を達成し、それらを事前に評価できるようになります。 確かに、いくつかの問題はまだ発生する可能性がありますが、作業中は雪玉のようには成長しません。 後で、古いフィールドを取り除くことができます。 タイムゾーンに関する情報は、オペレーティングシステムまたはユーザー設定から取得できます。 以下に、データベース内の2つのタイプの互換性に関する情報を投稿しました。

• 列タイプをDateTimeからDateTimeOffsetに変更すると、暗黙的な変換が機能します。 時間オフセットは+00：00になります。 別のタイムゾーンを指定する必要がある場合は、一時列を使用する必要があります。
• 文字列への値のフォーマットがサポートされています。
• サポートされているすべての演算子による比較。
• リスクのないSYSDATETIMEOFFSET（）はGETDATE（）を置き換えることができます
• DateTimeとDateTimeOffset間の割り当ては、暗黙的な変換で機能します。

運営	T-SQL	解説
DateTimeをDateTimeOffsetに変換	TODATETIMEOFFSET（datetime_field、「+ 00：00」）	オフセットを追加して値を取得+00：00
DateTimeOffsetをDateTimeに変換	CONVERT（DATETIME、datetimeoffset_field） -または-SET @datetime = @datetimeoffset	オフセット情報は失われます。 変換中、オフセットは単に無視されます。 たとえば、「2017-04-05 10:02:00 +01：00」の場合、「2017-04-05 10:02:00」になります。
現在の日付/時刻	SWITCHOFFSET（SYSDATETIMEOFFSET（）、 '+ 00：00'）	これらは2つのチームです。 結果はUTCゾーンのポイントになります
組み込みの操作	DATEPART、DATEDIFF、BETWEEN、<、>、=など	DATEDIFF、BETWEEN、および比較操作は、UTCオフセットを持つ値として表されるDateTime値で、時間オフセットを考慮に入れます
書式設定	CONVERT（NVARCHAR、datetimeoffset_field、103）	DateTimeの場合と同じ結果を取得します。

システムですでにこれを行った人たちから、そのような変化についての話を聞くのは非常に興味深いです。 また、システム内のタイムゾーンを誰がどのようにサポートしているか。