「DB設計したいNight #4 そーだいさんと失敗から学びながらDB設計したいnight」参加レポート

dbnight.connpass.com に参加してきたのでそのレポートです。Togetterでいいんじゃないかと思うくらい、Tweetの引用がメインになってます。

概要

迷えるDB設計初心者達のための勉強会です。普段はハンズオン形式ですが、今回はそーだいさんと nakunaruさんのパネルディスカッション形式です。

イベントページより

具体的なDB設計の悩みに対して、そーだいさんや主催チームが語るパネルディスカッション形式でしたが、問いかけをして参加者に考える時間を与えたり、時折参加者にアンケートや質問を取ったりとその場に合わせた・その場にいるからこそ享受できる学びがある勉強会でした。

スポンサー様

会場提供のPIXTA様、綺麗なオフィスのおかげで勉強会が捗りました！ありがとうございます。

フード・ドリンク等の費用サポートのForkwell様、懇親会でも有意義な議論ができました、会話も弾みました。ありがとうございます。

#また出たなForkwell #また来てねSony #dbsekkeinight
— そーだい@初代ALF (@soudai1025) 2019年5月16日

具体的な学び Twitterより抜粋

やるべきだったこと
「対応するマスタを新規定義するのがよかったのでは」
教訓としては「DB設計に限らず、予想外の事態でちょっとしたテクニックで逃げたくなるときはよくあるけど、そういう時こそ基本を大事にするべき」
#DBSekkeiNight
— papageno (@pa_pa_geno) 2019年5月16日

銀行システムにおける支店の扱いに関する問いについてです。格納するデータの形式を工夫することで想定外の事態に対応するのも可能だけど、そんなときこそ基本が重要という刺さる言葉をいただきました。

>アプリケーションのクラスとテーブルをイコールにする先入観があると辛くなりがち。親テーブル子テーブルをつくる。VIEWを使るなどいいかも。Posgreは継承がある
Railsでよくやってしまうやつ！#dbsekkeinight
— ﾅｶﾞﾓﾄ (@ngmt83) 2019年5月16日

「賃貸物件と売買物件を扱う事例。多くの項目が共通だが一部が異なるので、STIで 1テーブルに詰め込んだ。
特にウェブ系とかでやりがち。データの構造はプログラム上の親子関係である必要はない。例えば、ビューで文脈ごとのスキーマで見せるとか。物件・鎮咳・売買に分割してもいい。
#DBSekkeiNight
— n.siena (@n_siena) 2019年5月16日

「他に、クラスを観点や部品ごとに分割して、それに対応してテーブルも分割してもよい。
.oO(個人的にはこれは好みなのだけど、必ず「じょいんがー」と騒ぎ出す人が出てくる -_-;
#DBSekkeiNight
— n.siena (@n_siena) 2019年5月16日

不動産に関して賃貸と分譲などをどう設計するかという問いについてです。 STIでどうにかしてしまいがちだけど正規形では当然ないし、想定外に対応しにくいし、分割しておきたいですね。

>VIEWのVIEWはダメ！
>フィクション()だけど、マテビューからマテビュー作っちゃダメ#dbsekkeinight
— ﾅｶﾞﾓﾄ (@ngmt83) 2019年5月16日

>VIEWでVIEW作ると古いキャッシュが残り、それを順番で解決しようとしたりして辛い#dbsekkeinight
— ﾅｶﾞﾓﾄ (@ngmt83) 2019年5月16日

あまりVIEWを使っていないので踏んだことはないですが、VIEWでVIEWを作ることは地雷だとしっかり覚えておきます。

Q.正規化をどのくらいするか
A.100%やりたいなあ
やりきった上で正規形を崩すのはあり。
よくある失敗は論理設計と物理設計は一緒にやってしまうことで起きる。#dbsekkeinight
— ﾅｶﾞﾓﾄ (@ngmt83) 2019年5月16日

1人でDB設計を考えているときに論理設計と物理設計が混ざることはなんども経験があります。またチームでDB設計に関する議論をするときも混同して議論が右往左往したこともありました。注意していきたいです。

Q. VIEWの使い方
- データ移行のためにVIEWを一時的に使ったり、SELECTを簡単にするためにのみ使う
- ユーザの状態から次のアクションをレコメンドするのに使っている#DBSekkeiNight
— ﾅｶﾞﾓﾄ (@ngmt83) 2019年5月16日

参加者にVIEWの使用例を聞いた結果です。実際の具体例をあげてもらったおかげで理解が捗りました。

「そーだい氏の場合。実体化ビューや多数の索引を使うのは設計が拙かった場合が多いので再設計を推奨。ビューを使うのは:
1. リファクタリングでの後方互換性のため。
2. セキュリティ上、データアクセスを制限するため。
3. フラグ判定で有効なものだけ結合して取得したりするため。#DBSekkeiNight
— n.siena (@n_siena) 2019年5月16日

知見の塊ですね。マテビューなどのRDBの機能を飛び道具と呼んでいたのが印象的で「飛び道具に頼ってしまうのは設計が誤っているとき」というのはしっくり来ました。

「いらないと思ってカラムを消して、後々困ったことある人います？」
↓
（今日の会場では）誰もいない
↓
「じゃあきっと消しても大丈夫ですねw」
#DBSekkeiNight
— papageno (@pa_pa_geno) 2019年5月16日

使わなくなったカラムはビジネス上の都合で消すという確信を持てるまでの調査時間が取れない時を除いて消したほうがいい。 #DBSekkeiNight
— yuyasat (@yuyasat) 2019年5月16日

Oracleだとカラムに「使わなくなった」フラグをシステム的に立てることができる。実際に読みに行かないし、パフォーマンス的にも無いものとして扱える。#DBSekkeiNight
— papageno (@pa_pa_geno) 2019年5月16日

Q「使わなくなったカラムを old_xxx みたいにリネームして残しておくのはどう?
A「コメントに、残しておく期限を残しておく等すると、削除する決断をしやすくなる。
.oO(なるほど。十分に影響がないことが確認できたら削除する派だけど、これはいいプラクティスだなー。採用したい。
#DBSekkeiNight
— n.siena (@n_siena) 2019年5月16日

不要そうなカラムなどを削除するときのTips非常によかったです。消したい時はぜひ参考にします。