差分の変更とロールバック

これは誰に向けたものですか

「保存されたテーブル」を継続的に進化させ、リリース前に明確な変更範囲とロールバック パスを必要とするユーザー向け。

これで解決すること

リリース前に「何が変更されたのか」「どのようにロールバックするのか」を明確に説明できるため、スキーマ変更の実行リスクが軽減されます。

前提条件

• Saved Table が現在のワークスペースにロードされます。
• このテーブルは変更されており、保存されたバージョンとは相違点が存在します。

ステップ

1. テーブル設定エリアで、「View schema changes」ボタンが表示されるかどうかを確認します。結果: 保存されたテーブルがロードおよび変更された場合にのみ表示されます。
2. 変更差分を開いて、最初にテーブルレベルの変更を検査し、次にフィールドとインデックスの変更を検査します。結果: 変更の範囲と影響を明確に特定できます。
3. diff ダイアログから ALTER スクリプトをコピーします。結果: 前方実行用のスクリプトを取得します。
4. 必要に応じて、ロールバック スクリプトを展開してコピーします。結果: この変更を元に戻すためのスクリプトを取得します。
5. Saved Tables の対象項目から履歴エントリを開きます。結果: バージョン履歴を入力し、各スナップショットを検査します。
6. 復元が必要な場合は、履歴からターゲット バージョンを選択し、ロールバックを実行します。結果: 現在のワークスペースは、選択したバージョンの状態に戻ります。
7. 進化の過程を視覚的に確認する必要がある場合は、バージョン履歴の「タイムライン再生」を開きます。結果: システムはテーブル構造の古いものから新しいものへの変更プロセスを視覚的に再生し、進化の軌跡をチームに簡単に示すことができます。

いつ完了するか

• 変更項目は一つ一つ確認され、スクリプトは順方向実行とロールバック復元に明確に分けられます。
• キーのバージョンは履歴から見つけることができ、必要に応じて安定したバージョンを復元できます。
• リリース前に実行可能なロールバック計画がある。
• タイムライン再生を使用した場合、チーム メンバーはテーブル構造の進化ロジックを理解できます。

よくある落とし穴と障害の処理

• 保存されたテーブルがロードされていないか、差分が存在しない場合、差分エントリは表示されません。これは予期された保護動作です。
• ロールバック スクリプトは常に直接実行できるとは限りません。実行する前に、実際のデータベースの状態を再確認してください。
• バージョンを削除するか、保存を上書きすると、履歴のトレーサビリティが変更されます。マイルストーン バージョンを保持します。
• ロールバック スクリプトではなく ALTER スクリプトのみを確認すると、障害シナリオでの回復コストが増加します。
• タイムラインの再生はバージョンのスナップショットに基づいています。中間バージョンが削除された場合、再生ではそのバージョンがスキップされ、前後の違いが直接表示されます。