DBの設計してきました

バックエンド（サーバサイド）エンジニアです！と名乗りだして半年が経ちました。
成長が亀の歩みなのですが、なかなか体験できなかったDB設計について実際にやってみよう！という
イベントがあったので、参加をしてきました🐶

参加背景

Railsでロジックを書き始めた頃、よく思うことがありました。
「このロジックはモデルに書くべきなの？
コントローラに書くべき？」
「スコープ（モデルからデータを引っこ抜くORマッパーが書いてあるメソッド）が欲しかったら、モデルに書くのかな
…あれ？似た処理がコントローラにある気がする（幻覚）」
といった具合に。

私は歴が浅いこともあり、言われるがままの要件を満たす実装をしがちでした。
cssを書いている時も感じていましたが、
「これ、同じ部品あるんじゃ？」「このバリデーション、viewにいちいち書くのか…」
と感じつつも、要件が投げられるからという理由でバックエンドのリファクタを実施できなかった後悔があります。

メモリの使用率などを計算に入れてコーディングしたためしはないですが、
false, nil以外は真というRubyの性質上、判定文で使用されなかった変数もメモリを取ったまま、処理が実行されるという事に気付きました。

データ抽出もORマッパーに頼りっぱなし、いまだに疎い部分はたくさんありますが、自分の書いたスコープがテーブルの中を何往復しているかという想像も出来ていませんでした。

気がつけばmackaelがアラートを出し、CPU負荷率の調査の為にログを眺めていてもSQLの意味がわからない…

上記に後悔ばかりが連ねてありますが、そもそもどこから手をつけるべきなのかが全く見えていませんでした。
そんなもやもやを抱えている時にSQLアンチパターンと出会い、Rubyの問題にしろ、Railsの問題にしろ、ちょっとずつ知ることから始める事にしました。

いらないものは実装しない

YAGNIの原則というものがあります。
私はプライマリキーはどのテーブルにもある！という謎の宗教観の人間だったのですが、
実はそうでなくて、これはアンチパターンの一種であるIDリクワイアドに見事にハマってしまっている状態だという事に気づかされました。
無意識にガーッと書いたER図の中にid, user_id...などが軒を連ね…
参照される必要のないカラムは'もしかしたら'プロダクトが成長した暁に、DBの容量を逼迫するかもしれません。
ついつい入れてしまった『参加者をカウントする数字を格納するカラム』もきっとアプリ側で解決する問題でしょう…

他の参加者の方の設計を見て考えさせられたのは、上手にテーブルを分割して、要件を実現するだけでなく、後々の運用までをうっすらとでも考えている見通しの意図でした。

DB設計はシンプルさが重要で、頼まれた要件を渡すように作りこむのかがDB・アプリ技術者の腕にかかっていて、それはシームレスに行われるものだと実感しました…。

それからどうする？

最近はサーバレスというものが流行っていますが、私はそれにしばらく着手せずに、上にあげた後悔と向き合うだろうと思います…
後本当はプリンシパルオブプログラミングもちゃんと読み込みたいです。
速読術が欲しいなあ…