データベース・リファクタリング

データベース・リファクタリング

間違えないで欲しい。データベースのリファクタリングは困難だ。カラムの名前を変更するといった簡単な変更ですら，スキーマ全体や，オブジェクト，永続化フレームワーク，アプリケーション層に影響を及ぼすため，DBAにとっては非常に取り入れにくい手法に思えてしまう。
『データベース・リファクタリング』では，一連の決まったプラクティスの概略が述べられており，プロのDBAがデータベースの設計や開発にアジャイルな手法をどう取り入れるべきかが，明確に示されている。ScottとPramodは，各データベース・リファクタリングを実際に行うには何が必要かを注意深く詳細に記すことで，この手法が実施可能なことを証明し，広く採用される道を開いた。

アプリケーション開発ではアジャイル手法が浸透しつつある一方で、データベース設計は初めにすべてを計画し尽くす逐次型の開発を前提としたままである。このような状況を改善して、データベース設計の領域にもアジャイルな開発を導入するための手法を、一つ一つ解説されている。
「あるテーブルから別のテーブルにカラムを移動する」といった操作を実現するために、マルチアプリケーションの環境では、一斉移行が困難であるという問題に直面する。この場合の処方としては「移行期間を設け、その期間中は両方のテーブルにカラムを定義し、トリガーによって値の同期を図る。」など、逐次的にスキーマやデータの変更を行う術を説明する。
トリガーを多用することや、各アプリケーションの保守担当者が「移行期間中にアプリケーションを変更する」という変更管理の手法、セマンティクス(データの意味)を変えずして稼働中のアプリケーションやスキーマに手を加えることなど、確かにハードルが高そうで、啓蒙が求められている分野なのかもしれないと思った。

• • • • -

個々の手法の解説は、「説明」「動機」「トレードオフ」「スキーマ変更手順」「データ移行手順」「DBアクセスプログラム更新手順」が淡々と説明される。
一方で、わかりやすいと思ったのが、「リファクタリングの手法を両論併記して、そのメリット・デメリットを公平に説明している」ことだった。
例えばコード値などの、データの取りうる値を規定することによって品質を保ちたいといった場合、「参照用テーブルの追加」パターンを適用して参照整合性を保つ方法と、「カラム制約の導入」パターンを導入して、DBMSの機能を使って直接的に値を規定する方法それぞれについて、トレードオフが説明される。(そもそも、アプリケーション側で入力値を規定するという方法もあろうけれど、もちろんDBリファクタリングのパターンとしては説明されていない)
「ハードデリート(物理削除)の導入」と「ソフトデリート(論理削除)の導入」についても同様である。

• • • • -

実際に、どの程度の組織にまで浸透している考え方なのかに興味を持った。