DBはバックエンドだけのものではない
フロントエンド、モバイル、インフラ、データ分析、AI活用、社内ツール開発。どの専門でも、最終的にはデータを扱います。
全エンジニアは、今の専門を問わず、データベースに詳しくなった方がよいです。
理由は単純です。アプリケーションの価値は、画面やAPIだけでなく、正しいデータを安全に保存し、必要な形で速く取り出せるかに大きく左右されるからです。
DB力は4分野で見る
DB力は、少なくとも次の4分野に分けて考えます。
| 分野 | 問われる力 |
|---|---|
| SQL | 必要なデータを正しく速く取り出せるか |
| テーブル設計 | データの関係を壊れにくく設計できるか |
| データ移行 | 既存データを失わずに新しい形へ移せるか |
| チューニング | 遅いクエリを分析し、改善し、監視できるか |
この4つを、どれだけハイスピード・ハイクオリティでできるかが重要になります。
1. SQL
SQL力は、構文暗記ではありません。
必要なのは、テーブルを見て、欲しい結果から逆算して、正しいクエリを書ける力です。
最低限できるようになりたいこと:
SELECT/WHEREで必要な行を取るJOINで複数テーブルをつなぐGROUP BYで集計するNULLを正しく扱うINSERT/UPDATE/DELETEを安全に実行する- トランザクションで変更を守る
- 実行前に影響範囲を確認する
SQLが弱いと、実装側で無理なデータ加工をしがちです。DBで絞れるものをアプリで絞り、JOINできるものを複数APIで取ってつなぎ、集計できるものをメモリ上で処理する。こうした実装は、最初は動いてもデータ量が増えると破綻します。
2. テーブル設計
テーブル設計は、画面に表示する形をそのまま保存する作業ではありません。
見るべきもの:
- エンティティは何か
- 1対多、多対多の関係はどこか
- 主キーは何か
- 外部キーで守る関係は何か
NOT NULLにすべき列は何かUNIQUEにすべき列は何か- 正規化すべき重複は何か
- あえて非正規化する理由はあるか
- インデックスをどこに貼るか
良いテーブル設計は、アプリケーションコードを楽にします。逆に、テーブル設計が曖昧だと、アプリ側で例外処理、重複チェック、整合性チェックが増えます。
3. データ移行
データ移行は、DB作業の中でも事故が大きくなりやすい分野です。
新しいカラムを追加するだけなら簡単に見えます。しかし、本番には既存データ、古いアプリ、新しいアプリ、バッチ、管理画面、外部連携があります。
安全な移行では、次を考えます。
- 既存データを失わないか
- 旧アプリと新アプリが共存できるか
- ロールバックできるか
- 大量データ更新でロックしないか
- バッチ移行を途中再開できるか
- 移行後の件数や差分を検証できるか
- バックアップとリストア手順があるか
DB変更は、コード変更より戻しにくいことがあります。特に削除、型変更、カラム分割、テーブル分割は慎重に扱います。
4. チューニング
チューニングは、感覚でインデックスを貼る作業ではありません。
基本の流れ:
遅いクエリを見つける
EXPLAIN / EXPLAIN ANALYZE で実行計画を見る
件数・選択率・JOIN順序・ソート・ロックを見る
インデックスやSQLを書き換える
改善前後を測る
監視に反映する
チューニングでは、次のような観点が必要です。
- N+1クエリ
- 不要な全件スキャン
- 貼り方の悪い複合インデックス
ORDER BYとLIMIT- 集計の重さ
- ロック待ち
- コネクション枯渇
- スロークエリログ
- p95 / p99 レイテンシ
速いかどうかは、ローカルの数件データでは分かりません。本番に近いデータ量とアクセスパターンで見る必要があります。
4分野はつながっている
この4分野は独立していません。
SQLが弱いと、テーブル設計の良し悪しを判断しにくくなります。テーブル設計が弱いと、チューニングで無理が出ます。データ移行が弱いと、設計改善を本番に反映できません。チューニングが弱いと、正しい設計でも運用で詰まります。
SQL
-> データを読む力
テーブル設計
-> データを壊さない構造を作る力
データ移行
-> 構造変更を安全に届ける力
チューニング
-> 増えたデータでも耐える力
DBに強いエンジニアは、この4つをつなげて考えます。
初学者の到達ライン
最初に目指すラインは、次の状態です。
- 基本的なSELECTを自力で書ける
- JOINの結果を予想できる
- テーブルの主キー・外部キーを説明できる
NOT NULL/UNIQUE/ 外部キー制約を使い分けられる- 危険なUPDATE / DELETEの前にSELECTで確認できる
- 簡単なEXPLAINを読める
- DB変更を一発本番実行しない感覚がある
ここまで行くと、どの専門でもDBを怖がらずに扱えるようになります。
中級者の到達ライン
中級では、次を目指します。
- 業務要件からテーブル設計できる
- 多対多、履歴、状態遷移を設計できる
- インデックスをクエリパターンから設計できる
- 後方互換性を保ってマイグレーションできる
- バックフィルをバッチで安全に実行できる
- スロークエリを見て改善方針を出せる
- DB負荷を監視し、再発防止できる
これはバックエンド専用スキルではありません。フロントエンドでも、APIの設計や画面のデータ要求を考えるうえで強力な武器になります。
まとめ
DB力は、SQLだけではありません。
- SQLで正しく読む
- テーブル設計で壊れにくく保存する
- データ移行で安全に変える
- チューニングで速く安定させる
全エンジニアがこの4分野を意識すると、実装の質が上がります。データを雑に扱うと、どれだけ画面やAPIがきれいでも、後から大きな負債になります。
