Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所

DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所

Avatar for soudai sone

soudai sone

July 08, 2025
Tweet

More Decks by soudai sone

Other Decks in Technology

Transcript

  1. 自己紹介
 曽根 壮大(40歳)
 Have Fun Tech LLC 代表社員
 株式会社リンケージ CTO

    兼 COO
 
 そ
 • 日本PostgreSQLユーザ会 勉強会分科会 担当
 • 3人の子供がいます(長女、次女、長男)
 • 技術的にはWeb/LL言語/RDBMSが好きです
 • コミュニティが好き たけ
 ね
 とも

  2. ここまでシンプルな実装を目指しましょうと強調してきました が、「シンプルな実装」とはなんでしょうか。RDBMSを使う上で シンプルな実装のヒントは正規化です。正規化のコツは次の ように表現できます。 
 • 事実だけを保存する 
 • 重複がない


    • 不整合がない
 • nullがない
 これらを意識して設計していくとシンプルな設計に近づいてい きます。
 また正規化を行う際はここまで説明したとおり、種別と状態を 考えることも重要です。ライフサイクルが違うデータは往々に して状態や種別が異なります。 場合によってはnullになるよう なカラムやUPDATEが必要なレコードは状態を持っている可 能性があります。こうしたテーブルが見つかった場合はより 深く考察する必要があります。 
 https://agilejourney.uzabase.com/entry/2022/07/28/103000
  3. そして最後にINDEXの数にも注目しましょう。主キーは必ずあ りますが、外部キー制約とユニーク制約を除いたINDEXは主 に検索のために必要なINDEXです。検索のWHEREの対象の 数だけそのテーブルの責務が大きいといえ、 4つ以上の INDEXが必要な場合も同じく深く考察する必要があります。 隠 れた状態をWHEREで絞り込んでいたり、種別をWHEREで絞り 込んでいるケースが見えてくることがあります。 


    このようにシンプルな設計を目指して考察を繰り返していくこ とが重要です。そして同じくらい重要なこととして認識すべき はイージーとシンプルは両立できる、ということです。 シンプ ルを目指し考察を繰り返すことがまさにデータモデリングであ り、変化に強い設計につながっていくのです。 
 https://agilejourney.uzabase.com/entry/2022/07/28/103000
  4. Make each program do one thing well. 一つのことに集中することで プログラムに不要な部分をなくせる。 不要な部分があると、

    実行速度が遅くなり、 不必要に複雑になり、 融通が効かない。 https://amzn.to/33QPAdv
  5. 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); 

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