【開発哲学5_2】『データベース・リファクタリング　データベースの体質改善テクニック』第２章　データベース・リファクタリング

感想

「データベース・リファクタリングもコード・リファクタリングと同じで、小さく変更しながら、情報や機能は何も変えないで、中身の品質を改善していく手法」

ってことを説明してる章だね。

詳細

見出しとしては、

1. コード・リファクタリング

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

3. データベース・リファクタリングの分類

4. データベースの不吉な臭い

5. データベース・リファクタリングの位置付け

6. データベーススキーマのリファクタリングを容易にするには

7. この章で学んだこと

てな感じ。

SQLやストアドプロージャ

なんかが出てきたね。

オブジェクト指向言語の基本と同じ

疎結合なDBを目指す。
👉密だと、一個の変更でスキーマが変更になったら目も当てられなくなる。
DBに直接アクセスするのではなく、フレームワークを介してやりとりする
👉変な変更や削除をなるべく回避＝レコードのカプセル化

って感じだね。
ま、基本だけど。

DBを変更しようとして失敗するよりも、

DBに一切変更を許さない（＝「変更は悪」みたいな）頑迷な会社や組織、エンジニアの方が問題。

顧客のニーズが変わるのが早くなってるし、今や、DBと連携してないGUIなんて存在しないから、
そんなことやってたら、使い勝手が悪すぎて、利用者から淘汰されるだけ。

そういう人ほど

P.23〜に書いてるとおりのことをやってるけどね。
・「なんでこの列とこの列は同じ値で列名まで同じなんだろう、、、」
👉エクセル表とかで作る人多いんだけど、それをACCESSに取り込もうとすると、列名が重複してるから別名付けられたりするし、そこですでにSQLまで組んでいると、コード自体を書き換えないとうまく動かないんだけどね。
・「名が重複はしてないけど、なんの目的の列なのか、どこにも一致していない同じ値が入った列が複数存在する。」
👉設計段階で見落としてるか、設計者が今後必要になるかもで設計当時になんとなく追加しといて、すでになんで追加してることを忘れてる。

一番最悪なのは

目先の作業に反応する人が増やし続ける列とクエリ

部署の管理職が素人で、各人に自由に使えるようにと、CRUD権限を全員に与えてしまう職場で起こりがち。
ACCESSを使うと結構簡単にDBのができちゃうから、

ACIDなDBを心がける

なんかを意識せずに、みんな目先で必要なクエリを組んでしまって、
クエリ名に名前も付けてないから誰が作ったのかもわからない。
しかも最初は10列しかなかったのに同じ値しか入っていない列が30列まで増えてる。
なんてことはよくある。

誰がやったか判って、聞いてみると

「テーブル全体で他の列なんてきちんと見てません。自分の作業にすぐに必要だったので増やしました。」

、、、他のこの列でできるし、使い終わったら消せばいいじゃん。

「いつかまた使うかもしれないので残してます」

、、、処理が重くなるし、クエリ増えちゃうと新しいクエリ追加できなくなるよ。

「それはその時に考えればいいので。」

って感じで、別にいいじゃんで残しとくと、今度は、そのいつか消すの列とかクエリを使ってさらに目先で反応してるから、別のサブクエリとか組んだりして目も当てられなくなるんだよね〜〜〜。
で、その時に大体頼って来られんだけど、、、

知るわけないじゃん！！！！！！

目先の作業に反応するばかりな職場だとDBはすぐに崩壊します。

まとめ

コードもDBもコンストラクションも、いつも書いてるとおり、

💃シンプルイズビューティフル🕺
を保つために、
定期的な棚卸しが大事。
要るものは残す。
要らないものは消す。