EXPLAIN の読み方と実行計画の改善 ハンズオン新着!!
「一覧画面が重い」「夜間バッチが終わらない」。この種の相談の多くは、特定の SQL が想定外のアクセス経路（実行計画）で動いていることが原因です。インデックスを追加すれば直ることもありますが、まず必要なのは「DB が今どう動いているか」を正…
非正規化のユースケースとトレードオフ ― 入門新着!!
RDB設計を学ぶと、まず「正規化しなさい」と教わります。第1〜第3正規形まで整えれば、データの重複が消え、更新時の矛盾（更新不整合）が起きにくくなる。これは正しい出発点です。
複合インデックスの設計とカーディナリティ入門新着!!
テーブルにインデックスを張ったのにクエリが速くならない。あるいはインデックスはあるのにスキャン行数が減らない。こうした状況の多くは、「複合インデックスの列順」と「カーディナリティ」への理解不足から生まれます。
TanStack Query 入門 — データフェッチの基本
React でサーバーからデータを取得するとき、useEffect + useState で素朴に書くと、ローディング状態・エラー処理・キャッシュ・再取得を毎回手書きすることになります。これらは本質的にアプリ固有のロジックではなく、「非同期…
インデックスの仕組みと設計原則：入門
「SELECT が遅い」「件数が増えたら急に重くなった」——こうした悩みの多くはインデックス設計で解決できます。本記事では、RDB（MySQL / PostgreSQL を想定）のインデックスがどう動くのかを、B-Tree の仕組みから設計…
DB設計の失敗パターンと改善事例 ― 現場でよく踏む地雷とその外し方
アプリケーションの寿命は、DB設計の質にかなり左右されます。コードはリファクタリングで直せますが、テーブル設計の失敗は本番データを抱えたまま直すことになるため、修正コストが桁違いに高くなります。
NFC来店・ポイント・承認フローを支える飲食店アプリのDB設計 — 100テーブル超を破綻させない5つの勘所
飲食店発見・来店ポイント系アプリのバックエンド設計に携わり、100テーブルを超えるスキーマを扱いました。「ユーザーが店を探す → NFCタグをスキャンして来店 → ポイントが貯まる → 投稿・応援・スタンプラリー」という体験を支えるデータモ…
計測データの時系列グラフAPIを「期間窓ごとに欠損ゼロ」で返す設計
計測機器向けのSaaS案件で、測定値の推移を「1ヶ月 / 3ヶ月 / 半年 / 1年」で切り替える折れ線グラフのAPIを担当しました。一見「期間で集計して返すだけ」ですが、実運用に載せると「測定が無い期間をどう扱うか」が最大の設計判断になり…
テーブル命名規約 — プレフィックスで種別を明示する設計
テーブルが数十を超えたあたりから、スキーマは「一覧を眺めただけでは構造がわからない」状態になっていきます。マスタなのかトランザクションなのか、それとも中間テーブルなのか。名前だけでは判別できず、毎回 DDL を開いて確認するという状況は珍し…
本番DB障害を「探索SQL→原因特定→修正SQL」のループでAIに調査させる
本番データベースの不整合や問い合わせチケットは、開発チームにとって避けて通れない仕事だ。「請求金額がおかしい」「あるはずのデータが表示されない」「二重に登録されている」——こうした報告が届くたびに、経験者が本番へおそるおそる SELECT …