【開発哲学5_6】『データベース・リファクタリング データベースの体質改善テクニック』第６章 構造リファクタリング
感想
意図とか手順を詳細に記述して、RDBMS（リレーショナルデータベース）の基本構造を理解できる章って感じ。
詳細
見出しとしては、
構造リファクタリングにおける共通問題
カラムの削除
テーブルの削除
ビューの削除
計算カラムの導入
代理キーの導入
カラムの統合
テーブルの統合
カラムの移動
カラム名の変更
テーブル名の変更
ビュー名の変更
テーブルによるLOBの置き換え
カラムの置き換え
関連テーブルによる１対多関係の置き換え
自然キーによる代理キーの置き換え
カラムの分割
テーブルの分割
てな感じ。
18項目はDB構造を変える
時に気をつけることとか手順について詳細に書いてるから、
マイグレーション時に、新しいGUIやアプリケーションに合わせてDB構造そのものを変える時とかにやると効果的かなあって感じ。
以前働いていた現場で
何を格好つけてるのか意味不明な会社だったんだけど、
DBのマイグレーション案件で、
・手順書や手引き書：全部英語（関西が本社 笑）
・DB：SQLServerで全てSQL
とここまではまだ、あながちあるんだけど、
職人気取りなだけのSE（てか、マニアなだけ）が、適当に作ってるDBだったのか
・ER図やテーブル関連図：
ない。
、、、
、、、、
！！！！👀！！！！
理由は、
SQLを読めばわかるから
そりゃ、
作った本人だからわかるかもしれないけど、
そもそもどんな名前のDBがどう連環しているのか、
SQL読み解いていけばわかるかもしれないけど、
SQL自体が単純に1000以上あったわ。
しかも整理もリファクタリングもされてない状態で。
こんなんひとつずつSQL開いてその度に全ての参照整合性とかキーとかを追っていかないといけないって
明らかに非効率で時間の無駄だろう、、、
この方法を採用してる会社自体が組織としてヤバいと思ったわ。
そこの現場を終えてからも
色々な会社を回ってるけど、
最近は、SEやDBAを育成してないからか、
どこの会社もそんな感じなのね。。。
と初めて知ったわ。
おそらくER図やテーブル関連図も知らない様子(´∀｀*)
ER図とかすらなくて、DBのリファクタリングなんてできるわけないやーん。
無理くりやっても危険すぎる。
まとめ
💃職人気質はどんな簡単な仕事も難しくするのが大好き
近い未来の自分の仕事さえも
↓
で結局、全部自分に返ってくるんだよねえ
本当の職人さんほど、目先の手間になっても、基本に忠実🕺
書籍紹介
SQLの基本を勉強したい方にオススメはコチラ
アクセスの資格取って、現場でも使い慣れた時に出会ったからすでに知ってる内容って感じだったけど、SQLやDBを初めて勉強する時に出会ってたらもっと効率的に習得できただろうなと思えた本。
結構、古い本だけど、
DBとはなんぞやから、基本的な使い方、考え方など解説がしっかりしていて、本の4章以降はリファレンスも付いてるので、最初の１冊はこれがオススメ。