【開発哲学5_7】『データベース・リファクタリング データベースの体質改善テクニック』第７章 データ品質リファクタリング
感想
全体的に、各レコードの制約やキー、Nullなんかの扱いを変更する時に気をつけることを書いてまとめてる章って印象。
コード（開発コミュニティ）のリファクタリングの基本を
普段から意識してると、
ああ、データベースでも通底する考え方は同じなんだな
って理解できると思う。
てか、
DBのリファクタリング自体を拒絶する人は、
どうか知らないけど、今や、DBでリファクタリングは避けて通れないし、
「変更は悪」
て考え方自体がもはや害悪でしかない。
ユーザーさんが、
DBに熟知してるわけはないし、
要らない制約
（例：アルファベッド入力できない）
がかかっていて、扱いにくい
とか
国際化＝グローバル（この言葉嫌い）化で、ITサービスなんて経営学では
ボーン・グローバル
とまで言われている時代に、
DB屋が、一切の変更を認めないなんてあり得ない
でしょ。
詳細
見出しとしては、
データ品質リファクタリングにおける共通問題
参照用テーブルの追加
標準的なコードの適用
標準的な型の適用
キー戦略の整理
カラムの制約の削除
デフォルト値の削除
ヌル不可制約の削除
カラム制約の導入
共通フォーマットの導入
デフォルト値の導入
カラムのヌル不可への変更
データの移動
プロパティフラグによるタイプコードの置き換え
てな感じ。
全体的には、
が、テーブルやDBの構造自体の大きなリファクタリング
（コードと違って、今回の小さなリファクタリングを行う前提
👉コードにおけるアンチリファクタリング（コードチューニング戦略）ではない。）
で、
前章を踏まえた上での、細かいDBの値や制約、カラムなんかを追加削除する方法をスッキリ書いてるって感じかな。
見出しだけ見ると、一見矛盾してるように思えるけどね。
現場では、その時々の要求に応じて、相反することをすることがあるから。
社内政治屋さんで多いのが
この章だと、
変なフォーマットやテンプレート
をデータベースやレコードにまで
見ればわかる！！！！！
で押し付けるなあって感じ。
例えば、
純粋に、
100000000
なら数字（＝numeric）だから、計算ができるのに、わざわざ、
100（百万円）
みたいにするとDBでは、
数字じゃなくて文字列
って扱いになるから、機械は計算できないでしょ？
にもかかわらず、
PC（パーソナル・コンピューター）
＝個人用の電子計算機
てことをよくわかってないのも加わって、
「俺たちのルールはこうだ！！！！！。読めばわかる。」
で、わざわざ使いにくくするオッサンとか多いんだよねえ。
パソコンは所詮、計算するための機械ですよ〜〜〜
プロパティフラグによるタイプコードの置き換えが
ここでは最後に来てるけど、
＜プロパティフラグをいかに使いこなせるか＞
が、そのDBの柔軟性や可変性を決める
と断言しても過言じゃないくらい、DB設計にフラグは重要。
無駄なカラムを維持
する必要まではないけど、何かしたいとか、こういうことがしたいと
コロコロ変わる要求に柔軟に対応しようとすると、
フラグで判別させて、SQLで絞り込む
とか
フラグを基準にどこかの値同士を結合させて、
別のカラムで作業列を作って値を抽出して、
結果だけ更新したり、出力カラムで値を保持する
なんてことはよくある話。
まあ、そーゆーときに、結構大事になってくるのが、
SQLでの値の切り出しや結合
だったりするんだけど。
まとめ
ここで書いてることをひととおり頭に入れたり、都度、読み返したりしながら、経験を積むのが一番かな。
エマーソンの言葉だったかと思うけど、
💃恐怖は常に無知から生まれる。
知識（＝開発哲学）は（困った時の）光である🕺
てことかな。
ま、自分もまだ駆け出しなんで、偉そうなことは言えないし、ゆーつもりもないけど。
今日は、
結構、作業が立て込んでいて、テレワークの合間で駆け足で読んだから、明日以降でちょい読み返そ
読み返したら、何か補足で追記するかもね〜〜〜〜🕺
今作ってるツールがいよいよ大詰めですーーーー！
明日で出来るかな。