「DB設計したいNight #4 そーだいさんと失敗から学びながらDB設計したいnight」参加レポート
dbnight.connpass.com に参加してきたのでそのレポートです。Togetterでいいんじゃないかと思うくらい、Tweetの引用がメインになってます。
概要
迷えるDB設計初心者達のための勉強会です。 普段はハンズオン形式ですが、今回は そーだいさん と nakunaruさんのパネルディスカッション形式です。
イベントページより
具体的なDB設計の悩みに対して、そーだいさんや主催チームが語るパネルディスカッション形式でしたが、問いかけをして参加者に考える時間を与えたり、時折参加者にアンケートや質問を取ったりとその場に合わせた・その場にいるからこそ享受できる学びがある勉強会でした。
スポンサー様
会場提供のPIXTA様、綺麗なオフィスのおかげで勉強会が捗りました!ありがとうございます。
フード・ドリンク等の費用サポートのForkwell様、懇親会でも有意義な議論ができました、会話も弾みました。ありがとうございます。
#また出たなForkwell#また来てねSony#dbsekkeinight
— そーだい@初代ALF (@soudai1025) 2019年5月16日
具体的な学び Twitterより抜粋
銀行システムにおける支店の扱いに関する問いについてです。 格納するデータの形式を工夫することで想定外の事態に対応するのも可能だけど、そんなときこそ基本が重要という刺さる言葉をいただきました。やるべきだったこと
— papageno (@pa_pa_geno) 2019年5月16日
「対応するマスタを新規定義するのがよかったのでは」
教訓としては「DB設計に限らず、予想外の事態でちょっとしたテクニックで逃げたくなるときはよくあるけど、そういう時こそ基本を大事にするべき」
#DBSekkeiNight
>アプリケーションのクラスとテーブルをイコールにする先入観があると辛くなりがち。親テーブル子テーブルをつくる。VIEWを使るなどいいかも。Posgreは継承がある
— ナガモト (@ngmt83) 2019年5月16日
Railsでよくやってしまうやつ!#dbsekkeinight
「賃貸物件と売買物件を扱う事例。多くの項目が共通だが一部が異なるので、STIで 1テーブルに詰め込んだ。
— n.siena (@n_siena) 2019年5月16日
特にウェブ系とかでやりがち。データの構造はプログラム上の親子関係である必要はない。例えば、ビューで文脈ごとのスキーマで見せるとか。物件・鎮咳・売買に分割してもいい。
#DBSekkeiNight
不動産に関して賃貸と分譲などをどう設計するかという問いについてです。 STIでどうにかしてしまいがちだけど正規形では当然ないし、想定外に対応しにくいし、分割しておきたいですね。「他に、クラスを観点や部品ごとに分割して、それに対応してテーブルも分割してもよい。
— n.siena (@n_siena) 2019年5月16日
.oO(個人的にはこれは好みなのだけど、必ず「じょいんがー」と騒ぎ出す人が出てくる -_-;
#DBSekkeiNight
>VIEWのVIEWはダメ!
— ナガモト (@ngmt83) 2019年5月16日
>フィクション()だけど、マテビューからマテビュー作っちゃダメ#dbsekkeinight
あまりVIEWを使っていないので踏んだことはないですが、VIEWでVIEWを作ることは地雷だとしっかり覚えておきます。>VIEWでVIEW作ると古いキャッシュが残り、それを順番で解決しようとしたりして辛い#dbsekkeinight
— ナガモト (@ngmt83) 2019年5月16日
1人でDB設計を考えているときに論理設計と物理設計が混ざることはなんども経験があります。またチームでDB設計に関する議論をするときも混同して議論が右往左往したこともありました。注意していきたいです。Q.正規化をどのくらいするか
— ナガモト (@ngmt83) 2019年5月16日
A.100%やりたいなあ
やりきった上で正規形を崩すのはあり。
よくある失敗は論理設計と物理設計は一緒にやってしまうことで起きる。#dbsekkeinight
参加者にVIEWの使用例を聞いた結果です。実際の具体例をあげてもらったおかげで理解が捗りました。Q. VIEWの使い方
— ナガモト (@ngmt83) 2019年5月16日
- データ移行のためにVIEWを一時的に使ったり、SELECTを簡単にするためにのみ使う
- ユーザの状態から次のアクションをレコメンドするのに使っている#DBSekkeiNight
知見の塊ですね。マテビューなどのRDBの機能を飛び道具と呼んでいたのが印象的で「飛び道具に頼ってしまうのは設計が誤っているとき」というのはしっくり来ました。「そーだい氏の場合。実体化ビューや多数の索引を使うのは設計が拙かった場合が多いので再設計を推奨。ビューを使うのは:
— n.siena (@n_siena) 2019年5月16日
1. リファクタリングでの後方互換性のため。
2. セキュリティ上、データアクセスを制限するため。
3. フラグ判定で有効なものだけ結合して取得したりするため。#DBSekkeiNight
「いらないと思ってカラムを消して、後々困ったことある人います?」
— papageno (@pa_pa_geno) 2019年5月16日
↓
(今日の会場では)誰もいない
↓
「じゃあきっと消しても大丈夫ですねw」
#DBSekkeiNight
使わなくなったカラムはビジネス上の都合で消すという確信を持てるまでの調査時間が取れない時を除いて消したほうがいい。 #DBSekkeiNight
— yuyasat (@yuyasat) 2019年5月16日
Oracleだとカラムに「使わなくなった」フラグをシステム的に立てることができる。実際に読みに行かないし、パフォーマンス的にも無いものとして扱える。#DBSekkeiNight
— papageno (@pa_pa_geno) 2019年5月16日
不要そうなカラムなどを削除するときのTips非常によかったです。消したい時はぜひ参考にします。Q「使わなくなったカラムを old_xxx みたいにリネームして残しておくのはどう?
— n.siena (@n_siena) 2019年5月16日
A「コメントに、残しておく期限を残しておく等すると、削除する決断をしやすくなる。
.oO(なるほど。十分に影響がないことが確認できたら削除する派だけど、これはいいプラクティスだなー。採用したい。
#DBSekkeiNight
所感・雑感
シンプルにそーだいさんすげえ!と感じました。tweetにも現れています。
DB設計のパターンというか実現するための手札というか想定する力というか、ポスグレチョットデキルさんすごすぎでは#dbsekkeinight
— ナガモト (@ngmt83) 2019年5月16日
ある概念・使用パターンを説明したいときに、すぐ適切な具体例でるのはんぱないな!
— ナガモト (@ngmt83) 2019年5月16日
経験のかたまりや!#dbsekkeinight
また、ディスカッションや懇親会で時折「これはx章にも書いてあることなのですが〜」「私はx章が好きなんですが〜」という声も聞こえてきたので、そーだい本を読んだらDB設計についてさらに理解が深まるだろうし、有意義な議論ができそうだと思いました。(読んでないと伝わらない話ばかりをされるわけではないです)
ということで買いました。頑張って読みます。*1著者が好きな章は16章らしいです。
最後に
こっちもいい勉強会の予感がしますね! dbnight.connpass.com
*1:現実と向き合う、向き合った話を書いたしんどい本だと懇親会で聞きました。酒の肴にはならないそうです笑