2017-07-13 10 views
0

データベースに変更管理を実装する必要があります。 変更管理では、データベースのスキーマまたはコードを意味するものではありません。私はデータを意味します。 たとえば、SQLデータベースに2人のユーザーのユーザーテーブルが含まれている場合。 ユーザ1のユーザ名を変更することは「変更」です。ユーザ2のステータスの設定は「変更」です。 これらのアクションを実行すると、ユーザー表内のデータに2つの変更が生じました。これらの変更をログに記録する(簡単にできる)必要がありますが、前の時点にロールバックして、前の構成をテストするか、悪いものをロールバックする必要があります。 私は、データベースデザインの壁にぶつかり、これをサポートする方法をとらえています。特に、RoleやUserRoleなどのリンクテーブルを導入する場合は特にそうです!アプリケーション変更管理

ご意見やご感想をいただければ幸いです。

ありがとう

答えて

1

これにはいくつか解決策があります。

従来のデータベース設計で最も自然なのは、各レコードに対して「有効/無効」の概念を導入することです。 。ユーザーID、ValidFrom - あなたの主キーが複合だろう

UserID UserName Status ValidFrom ValidUntil ... 
============================ 
1  Bob   1 1/1/2017 2/4/2017 
1  Simon  1 2/4/2017 null 
2  Mary   1 6/7/2016 7/7/2017 
2  Mary   2 7/7/2017 null 

:ユーザーのあなたの例の表の場合、それはようなものになるだろうつまり、すべての外部キーがこのコンポジットをリンクする必要があります。

すべてのテーブルに "valid_from/valid_until"を適用すると、どの時点でデータステータスが何だったかを確認できます。例えば

、あなたは「役割」テーブルを持っている場合:

RoleID RoleName Active ValidFrom ValidUntil ... 
============================ 
1  Admin   1 1/1/2017 2/4/2017 
1  Administrator 1 2/4/2017 null 

とロールにユーザーをマップするテーブル...

UserID RoleID . Status ValidFrom ValidUntil ... 
============================ 
1  1   1 1/1/2017 2/4/2017 
1  1   0 2/4/2017 null 

ユーザデータと役割を探していることでは、興味のある日付のデータを取得すると、その時点でアプリケーションの状態を収集できます。レコードを削除するのではなく、「ステータス」フラグを設定する必要があります(たとえば、私の例では、ユーザー1の役割1のメンバーシップは2/4で中止されました)。

これは特に簡単なことではありません。実際には、私がこれを使用したとき、私は時間が重要だったテーブルで "valid_from/until"を使用しただけです。

これは、アプリケーションレベルで対処することです。これは、マイクロサービスと最終的な一貫性がますます一般化しています。 Event sourcingCQRSは良い出発点です。しかし、これにはデータベーススキーマ以上のものが必要です。

+0

テーブルが1つしかない場合、このソリューションが動作することがわかりますが、UserRoleなどの依存関係がある場合、このアプローチはチェーンのすべての依存関係に対してどのように機能しますか? – user1474992

+0

@ user1474992 - デモンストレーションする質問を更新しました。 –

関連する問題