【開発哲学5_8】『データベース・リファクタリング　データベースの体質改善テクニック』第８章　参照整合性リファクタリング

感想

章タイトルのとおり、参照整合性（RI）についてまとめた章って感じ。

あくまでも個人的には、

アプリ側とDB側を

フィードバック⇄フィードフォワード

で意識してるから、DB側で各テーブル間に制約をかけるより、
アプリ＝入力側に制約を設けるから、あんまりDBの制約は使わないかなあ。
入力さえ制限かけちゃえば、DB側での統一性って目的は実現できちゃうし。
て感じ。
テーブルの制約は、アクセスとかで経験がある人はわかると思うけど、パフォーマンスと柔軟性を落とすからあんまりやりたくないし、使わないんだよねえ。

こんな書き方したらDB屋さんから、

「制約は必要でしょ？こいつわかってないな！」

て思われるかもしれないけど。

詳細

見出しとしては、

1. 外部キー制約の追加

2. 計算カラムへのトリガーの追加

3. 外部キー制約の削除

4. カスケード削除の導入

5. ハードデリートの導入

6. ソフトデリートの導入

7. 履歴のためのトリガーの導入

てな感じ。

ハードデリートやソフトデリートは

読んでるだけでも、恐ろしくて冷や汗で出そうだった。

あるレコードをアップデートするだけでも慎重にやらないとなあ

なのに、行自体をテーブルから直接削除なんて恐ろしすぎる。
ミスった時に、ロールバックできる保障もないし。

履歴のところは、

趣旨が違うかもしれないけど、テーブルに更新をかけるなら、

テーブル側に処理実行日時と処理エラー発生日時
＝タイムスタンプ

の列を設けておくなあ。
履歴用のテーブルをわざわざひとつ設けるより同じテーブル内で参照できるし。

カスケード

やったこともないし、できてもやらないなあ。
RDBMSだと、
こういう親子関係のレコードをキーで繋いでできなくはないんだけど、
これをやると、つながりが複雑になりすぎて、

変更可能性が極端に落ちる＝柔軟性がない

DBになるからねえ。

個人的には

マスターDBから、クエリかミラーで目的専用のテーブルを追加して独立させて、そこで作業させるかな。

マスターに直接、子や孫、ひ孫、玄孫、、、みたいなことをすると、収拾つかなくなるし、
管理を意識せずにやりたがる人ほど、

見れば分かる

て感じでER図すら作らないし、
こんな状態のER図は恐ろしく膨大な情報になるから、作ろうとしてもエラいことになる。
最終的に図に書き出して管理する意識が最初から有ればそもそもやらない。
駆け出しの素人や後の管理を考えないスタンドプレーはやろうとしがち。

できないとやらない

の違いが分かってないからね。
RDBMSは、キーさえあれば、いくらでも繋げようと思えば繋げられちゃうけど、

何でもかんでも繋げりゃいいてもんじゃない

まとめ

💃DBも結局、色即是空＝ひとつは全て。全てはひとつ。
👉どこかのレコードやカラム、テーブルばかりに気を取られていると、DB全体の品質は上がらない。

木を見て、森を見ず

にならないように、RDBMSでもアプリ側まで含め、全体を意識🕺