変化に強いテーブル設計の勘所 / Table design that is resistant to changes

by soudai sone

Slide 1

Slide 1 text

PHPカンファレンス新潟2025 & JJUG CCC 2025 Spring 変化に強いテーブル設計の勘所  - AIにできないことをエンジニアリングする 

Slide 2

Slide 2 text

今日のお話すること      What is it?

Slide 3

Slide 3 text

時代は大AI（Agent）時代      What is it?

Slide 4

Slide 4 text

テーブル設計もAIに代替される？      What is it?

Slide 5

Slide 5 text

テーブル設計もAIに代替される？  ↓  そんなことはありません  What is it?

Slide 6

Slide 6 text

労力は代替できるが    能力は代替できない  What is it? – @t_wada

Slide 7

Slide 7 text

設計のサポートはしてくれるが    設計は自分で解決するしかない  What is it?

Slide 8

Slide 8 text

データベースの寿命は    アプリケーションよりも長い  What is it?

Slide 9

Slide 9 text

だからこそ今、    データベースが熱い！！  What is it?

Slide 10

Slide 10 text

1. 自己紹介  2. データベースは変化に弱い  3. 正規化とSimple is beautiful  4. AIとの設計の歩み方  5. おわりに  あじぇんだ

Slide 11

Slide 11 text

1. 自己紹介  2. データベースは変化に弱い  3. 正規化とSimple is beautiful  4. AIとの設計の歩み方  5. おわりに  あじぇんだ

Slide 12

Slide 12 text

自己紹介  曽根壮大（40歳）  Have Fun Tech LLC 代表社員  株式会社リンケージ CTO 兼 COO    そ  ● 日本PostgreSQLユーザ会勉強会分科会担当  ● 3人の子供がいます（長女、次女、長男）  ● 技術的にはWeb/LL言語/RDBMSが好きです  ● コミュニティが好きたけ  ね  とも 

Slide 13

Slide 13 text

Linkageは仲間を募集しています！ ● 事業開発をやっていきたい人  ○ 経験者じゃなくてもOK  ○ Extreme ownership を持って Just do it できる人  ○ PdM,PjM,PO,BizDevとかなんでもできます  ○ 年齢関係なく裁量があるのが文化  ○ 興味があればカジュアル面談しましょう！  ● もちろんPHPerも募集中です！！！ 

Slide 14

Slide 14 text

1. 自己紹介  2. データベースは変化に弱い  3. 正規化とSimple is beautiful  4. AIとの設計の歩み方  5. おわりに  あじぇんだ

Slide 15

Slide 15 text

データベースは変化に弱い      データベースは変化に弱い

Slide 16

Slide 16 text

データベースは変化に弱い  ↓  なぜか？  データベースは変化に弱い

Slide 17

Slide 17 text

● DELETEやUPDATEはデータが変化する  ○ 当たり前だがcommitされたデータは戻せない  ● カラムを追加したとき、過去のデータ対応が必要  ○ INSERTなどの前後のアプリケーションの互換性を  考慮する必要がある  ● 一度作ったテーブルやデータを消して良いかわからない  …etc  データベースは変化に弱い

Slide 18

Slide 18 text

サービスが成長すると    自然とデータベースも肥大化する  データベースは変化に弱い

Slide 19

Slide 19 text

その結果……      データベースは変化に弱い

Slide 20

Slide 20 text

● 本番にALTERを流したらロックで  サービスが死んだ  ● 特定のカラムを確認するif文の列挙が辛い  ● SELECTするまで結果がわからない  ● テーブルの変更が怖い  データベースは変化に弱い

Slide 21

Slide 21 text

ビジネスは常に変化する      データベースは変化に弱い

Slide 22

Slide 22 text

ビジネスは常に変化する  ↓  仕様変更は常にある  データベースは変化に弱い

Slide 23

Slide 23 text

例えば会員機能      データベースは変化に弱い

Slide 24

Slide 24 text

create table users( id bigserial constraint users_pk primary key, name text not null, birthday date not null, email text not null, hashed_password text not null ); create unique index 　users_email_uindex　on users (email);  

Slide 25

Slide 25 text

よく見るテーブルだけど？      データベースは変化に弱い

Slide 26

Slide 26 text

？？？「LINE認証を追加したいんだけど」      データベースは変化に弱い

Slide 27

Slide 27 text

？？？「LINE認証を追加したいんだけど」  ↓  カラム追加すればえぇやろ！  データベースは変化に弱い

Slide 28

Slide 28 text

alter table users add line_id text; alter table users add line_token text; create unique index users_line_token_uindex on users (line_token); create unique index users_line_id_uindex on users (line_id);

Slide 29

Slide 29 text

これが様々な問題を生み出す…      データベースは変化に弱い

Slide 30

Slide 30 text

● メールアドレスとパスワードは必須  ○ LINE認証でアカウント登録してもemailとpasswordを登録する必要がある  ○ ユーザの手間は減っていない（むしろ増える）  ● この問題はLINEの認証情報を別テーブルにしても同じ  ○ emailとpasswordをnullにする必要がある  ○ nullを許可したときにemailがUNIQUEでなくなる  userテーブルにカラムを追加すると……

Slide 31

Slide 31 text

機能開発のためのテーブル変更が    ビジネス側に不要な制約を生み出す  データベースは変化に弱い

Slide 32

Slide 32 text

データベースは変化に弱い初期設計

Slide 33

Slide 33 text

データベースは変化に弱い初期設計仕様追加

Slide 34

Slide 34 text

データベースは変化に弱い初期設計仕様追加将来を見据えたテーブルの修正をしないと次の仕様追加に耐えられない

Slide 35

Slide 35 text

データベースは変化に弱い初期設計仕様追加仕様追加

Slide 36

Slide 36 text

データベースは変化に弱い初期設計仕様追加仕様追加マジカルな設計によって開発ができなくなる

Slide 37

Slide 37 text

データベースの寿命は    アプリケーションよりも長い  大切なことなのでもう一回

Slide 38

Slide 38 text

だからビジネスロジックは    アプリケーションで担保するべき  データベースは変化に弱い

Slide 39

Slide 39 text

　データベースよりアプリケーションのほうが絶対的に変化に強いです。  　テストコードも書きやすいし、振る舞いのテストもしやすいし、振る舞いの変更もしやすいしです。そしてデプロイもデータベースに比べて簡単です。   　データベースだとデプロイするときに、ロックのことを考えなきゃいけないですし、マスター・スレーブのデータの整合性を考えないといけません。   　例えば同じことが、トリガーやストアドとアプリケーションで出来ることが同じ場合、なぜアプリケーションが良いかというと圧倒的に元に戻しやすいし、変更しやすいからです。  　だからこそシステムの柔軟性を意識する際にRDBとアプリケーション側の責任分界点を意識することが大切です。  https://soudai.hatenablog.com/entry/2017/12/27/080000

Slide 40

Slide 40 text

そうは言っても    テーブル変更は避けては通れない  データベースは変化に弱い

Slide 41

Slide 41 text

データベースに状態を持たせない    データベースには事実のみを保存する  データベースは変化に弱い

Slide 42

Slide 42 text

そのために必要なのが正規化      データベースは変化に弱い

Slide 43

Slide 43 text

1. 自己紹介  2. データベースは変化に弱い  3. 正規化とSimple is beautiful  4. AIとの設計の歩み方  5. おわりに  あじぇんだ

Slide 44

Slide 44 text

データベースの道はすべて    正規化に通ずる  正規化とSimple is Beautiful

Slide 45

Slide 45 text

正規化のコツ      正規化とSimple is Beautiful

Slide 46

Slide 46 text

ここまでシンプルな実装を目指しましょうと強調してきましたが、「シンプルな実装」とはなんでしょうか。RDBMSを使う上でシンプルな実装のヒントは正規化です。正規化のコツは次のように表現できます。   ● 事実だけを保存する   ● 重複がない  ● 不整合がない  ● nullがない  これらを意識して設計していくとシンプルな設計に近づいていきます。  また正規化を行う際はここまで説明したとおり、種別と状態を考えることも重要です。ライフサイクルが違うデータは往々にして状態や種別が異なります。場合によってはnullになるようなカラムやUPDATEが必要なレコードは状態を持っている可能性があります。こうしたテーブルが見つかった場合はより深く考察する必要があります。   https://agilejourney.uzabase.com/entry/2022/07/28/103000

Slide 47

Slide 47 text

そして最後にINDEXの数にも注目しましょう。主キーは必ずありますが、外部キー制約とユニーク制約を除いたINDEXは主に検索のために必要なINDEXです。検索のWHEREの対象の数だけそのテーブルの責務が大きいといえ、 4つ以上の INDEXが必要な場合も同じく深く考察する必要があります。隠れた状態をWHEREで絞り込んでいたり、種別をWHEREで絞り込んでいるケースが見えてくることがあります。   このようにシンプルな設計を目指して考察を繰り返していくことが重要です。そして同じくらい重要なこととして認識すべきはイージーとシンプルは両立できる、ということです。シンプルを目指し考察を繰り返すことがまさにデータモデリングであり、変化に強い設計につながっていくのです。   https://agilejourney.uzabase.com/entry/2022/07/28/103000

Slide 48

Slide 48 text

情報と事実（データ）は違う      正規化とSimple is Beautiful

Slide 49

Slide 49 text

情報と事実（データ）は違う      正規化とSimple is Beautiful 生年月日は事実年齢はそのタイミングの情報

Slide 50

Slide 50 text

正規化はUnixの哲学にも通ずる      正規化とSimple is Beautiful

Slide 51

Slide 51 text

Small is beautiful.    小さいものは美しい  Unixの哲学

Slide 52

Slide 52 text

Small is beautiful. 小さなプログラムという発想 1. 小さなプログラムはわかりやすい 2. 小さなプログラムは保守しやすい 3. 小さなプログラムはシステムリソースに優しい 4. 小さなプログラムは他のツールと組み合わせやすい https://amzn.to/33QPAdv

Slide 53

Slide 53 text

Make each program do one thing well.    1つのプログラムには  1つのことをうまくやらせる  Unixの哲学

Slide 54

Slide 54 text

Make each program do one thing well. 一つのことに集中することでプログラムに不要な部分をなくせる。不要な部分があると、実行速度が遅くなり、不必要に複雑になり、融通が効かない。 https://amzn.to/33QPAdv

Slide 55

Slide 55 text

1テーブル、1責務      正規化とSimple is Beautiful

Slide 56

Slide 56 text

1テーブル、1責務  ↓  Simpleを目指す  正規化とSimple is Beautiful

Slide 57

Slide 57 text

SimpleとEasyは違う      正規化とSimple is Beautiful

Slide 58

Slide 58 text

正規化とSimple is Beautiful

Slide 59

Slide 59 text

正規化とSimple is Beautiful

Slide 60

Slide 60 text

SimpleとEasyは両立するし    質とスピードも両立する  正規化とSimple is Beautiful

Slide 61

Slide 61 text

Userテーブルの分割の場合      正規化とSimple is Beautiful

Slide 62

Slide 62 text

passwordは認証情報のみの情報です。一方のemailは認証情報のみに使われる情報だとするとpasswordと一緒にしておくのも合理的かもしれません。   　しかし、emailは「email情報単体で変更される」こともあれば、たとえばGitHubのように複数のemailを持つこともあるでしょう。  　このように、emailは認証情報以外の属性も持っています。こうした場合、emailにpinコードを送ってWeb画面で認証する、といったワンタイムトークンのような認証機能を実装すると passwordは不要になります。   　こうした運用を想定し、今回はemailとpasswordを別テーブルに分ける判断をしました。   　またこの設定であれば以下の図のように新たなログイン情報が必要になった際も対応することができます。   https://agilejourney.uzabase.com/entry/2022/07/28/103000

Slide 63

Slide 63 text

Slide 64

Slide 64 text

テーブルがSimpleだと    変化に強くなる  正規化とSimple is Beautiful

Slide 65

Slide 65 text

イミュータブルに設計する              正規化とSimple is Beautiful https://scrapbox.io/kawasima/%E3%82%A4%E3%83%9F%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%96%E3%83%AB%E3%83%87%E3%83%BC%E3%82%BF%E3%83%A2%E3%83%87%E3%83%AB [イミュータブルデータモデリング kawasima] [検索]

Slide 66

Slide 66 text

テーブルはSimpleが美しい      正規化とSimple is Beautiful

Slide 67

Slide 67 text

テーブルはSimpleが美しい  ↓  EasyではなくSimpleを目指す  正規化とSimple is Beautiful

Slide 68

Slide 68 text

1. 自己紹介  2. データベースは変化に弱い  3. 正規化とSimple is beautiful  4. AIとの設計の歩み方  5. おわりに  あじぇんだ

Slide 69

Slide 69 text

？？？「AIにテーブル設計してもらおう！」      AIとの設計の歩み方

Slide 70

Slide 70 text

？？？「AIにテーブル設計してもらおう！」  ↓  上手くいってる人、いますか？  AIとの設計の歩み方

Slide 71

Slide 71 text

LLMは単語に対して    ありそうな文言を回答する  AIとの設計の歩み方

Slide 72

Slide 72 text

LLMは単語に対して    ありそうな文言を回答する  AIとの設計の歩み方それっぽいテーブルは作ってくれるが、背景を知らないので良くある駄目なパターンを回答しやすい

Slide 73

Slide 73 text

LLMは単語に対して    ありそうな文言を回答する  AIとの設計の歩み方それっぽいテーブルは作ってくれるが、背景を知らないので良くある駄目なパターンを回答しやすい世の中のOSSの設計はEasyでDirtyな設計が多い敢えてそういう戦略を取っている OSSもある WordPressやRedmineのEAV(Entity-Attribute-Value)とか

Slide 74

Slide 74 text

大きな単位(機能とか)で任せるのは    プロトタイプ以外では悪手  AIとの設計の歩み方

Slide 75

Slide 75 text

大きな単位(機能とか)で任せるのは    プロトタイプ以外では悪手  AIとの設計の歩み方捨てるつもりならスピード重視で採用しても良いと思うが、結局は捨てられずにずっと利用されることでしょう

Slide 76

Slide 76 text

AIはダブルループではなく    シングルループ学習  AIとの設計の歩み方

Slide 77

Slide 77 text

AIとの設計の歩み方前提行動結果シングルループは実行結果に元に行動を変える

Slide 78

Slide 78 text

AIとの設計の歩み方前提行動結果ダブルループは結果から、前提を変えて根本から変更する

Slide 79

Slide 79 text

前提を見直すことは    人間の仕事（しばらくは）  AIとの設計の歩み方

Slide 80

Slide 80 text

前提を見直すことは    人間の仕事（しばらくは）  AIとの設計の歩み方要求は物理の世界にあって、要求の変更は人間にしかできないから

Slide 81

Slide 81 text

データモデリングは人がやって    モデリングのサポートでAIを活用する  AIとの設計の歩み方

Slide 82

Slide 82 text

● MarkdownからER図やDDLを生成させる  ● DDLからテストデータを生成させる  ● DDLから想定するユースケースを洗い出す  ○ そのユースケース別のSELECTのクエリ生成させる  ● PKの設定漏れやカラム名のタイポなどをレビュ－させる  ● JSONやCSVから必要なエンティティを取り出す  etc……  AIに得意なことをやらせる

Slide 83

Slide 83 text

時間があればデモ    多分ないので興味がある人は  あとで話かけてください  AIとの設計の歩み方

Slide 84

Slide 84 text

1. 自己紹介  2. データベースは変化に弱い  3. 正規化とSimple is beautiful  4. AIとの設計の歩み方  5. おわりに  あじぇんだ

Slide 85

Slide 85 text

データモデリングのスキルは    寿命が長いし、複利で効く能力  おわりに

Slide 86

Slide 86 text

しばらくはAIに代替できる仕事では無い      おわりに

Slide 87

Slide 87 text

しばらくはAIに代替できる仕事では無い  ↓  代替するのではなく、労力をサポートさせる  おわりに

Slide 88

Slide 88 text

おわりに

Slide 89

Slide 89 text

データモデリングの歴史は長い      おわりに

Slide 90

Slide 90 text

データモデリングの歴史は長い  ↓  本もサイトも豊富なので活用しましょう  おわりに

Slide 91

Slide 91 text

オススメ本      おわりに

Slide 92

Slide 92 text

ミック本は良い ● SQLの基礎本ミックさんの本は読みやすいし、正しい情報だし、とにかく良い https://amzn.to/3xHwP8R

Slide 93

Slide 93 text

DBは本から学べる ● DB設計の本 ● SQLの本も別にあるミックさんの本はオススメ。そしてこの本は2012年の本だが、未だ全く色褪せることなく現役で使える知識で、今でもみんなに勧める1冊。 https://amzn.to/3CGNm0p

Slide 94

Slide 94 text

頼む、読んでくれ！ ● 俺たちのt_wada ● 大事なことが沢山書いてある ● 7月に第2版がでるまぁとりあえず読んでくれ https://amzn.to/43J8hiR

Slide 95

Slide 95 text

現実に向き合った本 ● 令和の名著（当社調べ） ● PostgreSQL & MySQL 対応そーだい本、一度は読んで欲しい。あと 5年は現役で読める本だと思っているし、「失われた事実」とか「キャッシュ中毒」なんかは未だによく話をする。あと頑張ったら新刊出すかも。 (連載してたやつをまとめて) https://amzn.to/4jBL4nL

Slide 96

Slide 96 text

データモデリングはスキルなので    正しく学べば身につけることができる  おわりに

Slide 97

Slide 97 text

引用元 : ワールドトリガー 28巻

Slide 98

Slide 98 text

“大事なのはできるという経験を得ること”    – 宇宙兄弟 145話   おわりに

Slide 99

Slide 99 text

      おわりに Simple is Beautiful     

Slide 100

Slide 100 text

      おわりに Simple is Beautiful  ↓  常に追求した者だけが辿り着ける 

Slide 101

Slide 101 text

今、こだわり抜いた設計が    未来の自分を救うことになる  おわりに