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

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

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

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

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

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

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

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

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

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

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

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

Linkageは仲間を募集しています！

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

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

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

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

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

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

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

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

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

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);  

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

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

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

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);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

正規化とSimple is Beautiful

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

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

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

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

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

イミュータブルに設計する              正規化と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] [検索]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

オススメ本      おわりに

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

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

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

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

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

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

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

      おわりに Simple is Beautiful     

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

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

      おわりに

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

昨日の自分に誇れる    今日の自分になろう  おわりに

ご清聴ありがとうございました      まとめ

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

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

More Decks by soudai sone

Other Decks in Technology

Featured

Transcript