前回の記事の続きです！
1. テーブルをまとめる
↓のようなテーブル構成があるとします。
PKが同じユーザIDで、格納するデータが違う2つのテーブルです。
ログイン時間がアプリケーション上重要、もしくはログイン時間のレコードが存在しないことで何かしらの判断する場合別テーブルにしたほうがいいかと考えました。
この構成でレビュー頂いたところ指摘をいただき、1つのテーブルにまとめました。
ログイン時間がアプリケーション上重要、もしくはログイン時間のレコードが存在しないことで何かしらの判断する場合
ユーザテーブルのログイン時間列にデータがあるかどうかで判断すればいい話です。
もともとはこのように一つのテーブルにまとめようと考えていましたが、この列が条件分岐の判断材料になるなら別テーブルにしたのが最初の案です。
開発のしやすさ（SELECTする際のテーブル名で何をするかピンポイントで分かること）を考慮してテーブル構成をおざなりにするのは合理的ではありません。
ただ設計書などにこのログイン時間にどのような意味があるのかしっかり記載する必要があり、チーム内で周知する必要がありますね。（テーブル２つでも必要か。。。）
まあなんでもかんでもまとめればいい話ではなく、ログイン時間の重要性だったり、項目の多さだったりでテーブルを分けたほうがいい場合もあると思います。合理的に行きましょう。自戒。
2. FKの列名はPKと同じにしとき
X（旧Twitter）をイメージしてください。
ユーザテーブルとポスト内容を格納しているテーブルがあるとします。
↓イメージ
ポスト一覧テーブルにはどのユーザがポストしたか分かるようにポスト投稿ユーザID列を設けます。
FKはどのような意味のユーザIDか分かるように名前を設定しました。
設けるのはいいですが、
「ポスト投稿ユーザID」ではなく
「ユーザID」にしよう。です。
↓のようにする。
同じような状況がテーブル定義中にありました。
確かにPKとFKを別名にするとどの列とリレーションを持っているのか直感的に分からなくなります。
これも1.と同じでFKの意味合いを設計書にしっかり記載する必要があります。
設計者の自分は意味が頭に入っていますが、メンバーが増えた場合や見直す際に正しく伝わるように設計書はめちゃ大事に記載しましょう。
3. クラウドの知識があるとDB設計にも反映するかもね
セキュリティ上いろんな制限をかけたいと思っています。
その制限をDB上で設定しようと考えていました。
現状とあるクラウドサービスを利用してDBの環境を用意していますが、ここで色々調べてみるとクラウド側でいろいろ制限かけれますね。。。
2年くらい前にがっつり勉強しており、すこーーーーーーーしだけ知識があったのでこの制限はできないかなーっと考えてましたができそうです。
若干趣旨からずれましたが、クラウドの知識があることでDB設計に影響がありそうです。
また勉強すっか。
4. 終わりに
・データの整合性をとることを最優先にする
・設計書しっっっっっっっっっかり書くこと
・クラウドサービスを知ること
どれも当たり前のことですが、改めて頭に叩き込みこれからのDB人生に生かします。
これでDB設計のお話は終わりです。
一人では得なかった知識を今回得ることができました。
Dまだまだな部分はありますが、これからも精進していきたいと思います。
5. 予告
11月17日に投稿予定です！