Kaigi on Rails 2026 After Event from ピクシブ LT saki

Transcript

1. プロダクト成長につれて テーブル構造は枷になるか 共有資産になるか saki
2. ピクシブ株式会社 広告 テックリード & Vice Lead 初めてのRubyは1.8 初めてのRailsは2.3 saki @yensaki 3系でwhere メソッドに感動した
3. テーブルやカラムに、 実態に合わない名前を 残していませんか？
4. これは名前が重要な話 Rubyist一生聞いてる
5. しかし、初めから正解の名前は難しい 不確実な現実に沿って 仮置きして変えていく moroさん Kaigi on Rails 2025 Keynote
6. DBもそうしていきたいが DBはなかなかにしんどくないですか
7. 2つの例を紹介して 考えてみます
8. ケース1. アカウントとロールの紐づけ
9. アカウントにロールをつける場合 アカウントに、アクセスや編集などの権限を付与可能にする話だと想像してください
10. 中間テーブルの命名をよく見る account_roles …?
11. ロール付与者や有効期限が必要になったら？ 無機質な名前の割に存在感が強くなってしまった…！(困る)
12. ケース2. コンテンツの表示可否管理
13. リストページに掲載できないものを管理したい list_available …?
14. でもそれは、リストページ限定で使うのでしょうか？ 数ヶ月後にこんな展開に
15. Rails app 内側は新しい命名もできるが、カラムの方は残る list_availableカラムが #export_available? に使われる(困る)
16. こうして 最初に決めたテーブルが あとあとでまずいことに気づく
17. それぞれ、適切な概念があった
18. 適切な概念があった : ケース1 → イベント概念
19. 適切な概念があった : ケース2 → 本当の意味 概念的には listpage ではなく法的要件のコントロールだった
20. 動的に変更していきたいが …
21. 1000万件に膨れていても現実的に変えられる？ • 作り直す前提の設計なら問題なし • 仮に1000万件のテーブルに育っていたら…？ ◦ 本番データ移行は相当に大変 • 勘案して見送るケースが多い
22. 移行が大変ならば … Q: 作成時に概念を得ることは可能か
23. そもそも 概念って Rails + DB だけで扱う？
24. PdMや営業も不可視の概念を持っているのでは？
25. 特に現代は、 PdMや営業も可視の DBを使う
26. バラバラだと気付けないので 構造を揃える
27. 事業の構造を揃えてから DBの設計に反映させる 概念を揃える(データ構造を共有のものにする)
28. 概念の可視化は抽象的で 結構難しい ホワイトボードなどが 自由に描けてオススメ
29. データ構造が足枷になると Railsの良さが減ってしまう！ プロダクト概念を具現化した 共有資産にしていきたい end