はじめに
エンジニアになって結構経ちますが、
キャリアが主に組み込みエンジニアだったせいか、
これまであまりデータベースを利用することがありませんでした。
そんな私もWeb/モバイル開発の会社に転職し、
少しずつデータベースに触れることが増えてきたので、
ちょっとくらいお勉強しようかなと
達人に学ぶDB設計という本を読みました。
本記事は読書で得た知見や印象的だったところについてまとめたものです。
データベースの種類が異なっても基本的に設計の方法は変わらない。
結構意外でした。
同僚からNoSQLはNULLやカラムが空だったり色々大変と聞いていたので、
RDBやNoSQLで設計方法は多少変わるものと思っていました。
最初にデータがある。プログラムはその次にできる
これはちょっと違いますが、常日頃私が意識していることに近いと感じました。
実業務をモデルとしてデータベースやシステムに落とし込むわけで、
結局そのデータや業務がどう振る舞うのかが一番大切で、
そこをおろそかにしてはいけないと常々感じています。
論理設計のステップ
1. エンティティの抽出
2. エンティティの定義
3. 正規化
4. ER図の作成
よく手順を飛ばしてER図からやっていることが多い気がします。
これは言い訳ですが、ドキュメントとコードを別々に書くとメンテナンスが大変なこともあるので、
コードからドキュメントを生成する手法にしてます。
いい方法考えたいですね。
差分バックアップ
恥ずかしい話。実現方法を把握していませんでした。
完全バックアップはデータを全てコピーしますが、
差分バックアップはデータベースに対する変更履歴を元に操作を再現することで実現するそうです。
テーブル名は英語なら複数形で書ける。そうでなければそのテーブルにはどこか間違いがある。
これよく困っている気がします。
データにアクセスする時にUser.idなのかUser.idsなのか複数形ではないほうが直感的ではあります。
あくまでも本では複数形にできると紹介されており、複数形の命名をしろとは書いてありません。
可変町の文字列をキーに使用しない
自由に設定できるのでちょっとしたことで意図しない動作につながるそうです。
なるべく制約をもたせ、無法地帯とならないようにすることが大切だと思いました。
(私も禁忌を犯す！とかいいながらアンチパターンやることがまれに良くあります)
正規化はレベル5まであるが普通は3まで理解すれば十分
4、5いらないの！？
配列型を使用できるがなるべく使用しないほうがいい
機能として提供されているので何も知らなければ使ってしまいますね。
ダメな理由としては配列になっているとキーを元に一意の値としてレコードを取得できないからだそうです。
RDBにの思想に反していて、負債になるって感じですかね。
ダブルミーイング
現場でみたく○設計。
ほんとひどい。
終わり
以上です。
もっと色々勉強になることがわかりやすく書いてある良い本でした。
ぜひご一読ください。
個人的にはバッドノウハウやグレーノウハウの章が特に面白かったと思います。
参考文献
読んだ本です。