第25回: ビューとストアドプロシージャ — 共通SQLをDB側で管理する判断基準
「論理削除を除いた有効ユーザーを取得するSQL」や「集計結果を求めるSQL」が、コントローラー・バッチ・APIエンドポイントにそれぞれコピーされている状態は管理が困難です。1箇所の条件変更が漏れると、データの不整合を引き起こします。
Month
「論理削除を除いた有効ユーザーを取得するSQL」や「集計結果を求めるSQL」が、コントローラー・バッチ・APIエンドポイントにそれぞれコピーされている状態は管理が困難です。1箇所の条件変更が漏れると、データの不整合を引き起こします。
アクセスログや履歴データを1つのテーブルに蓄積し続けると、削除クエリが重くなり、バックアップに時間がかかり、インデックスが肥大化する問題が起きます。DELETE WHERE accessedat < '2024-01-01' を流すだけで数十分かかる、というケースも珍しくありませ...
「とにかく正規化すれば正しい」と思っていると、複雑なJOINが増えてパフォーマンスが劣化したり、集計クエリが毎回重くなったりする問題に直面します。一方で「非正規化でいいや」と安易に判断すると、データの更新異常や整合性の崩壊を招きます。
カラムに深く考えずNULLを許可した結果、アプリ側で if ($value !== null) が乱発され、仕様の解釈が人によって異なるトラブルが起きることがあります。「このNULLは未入力なのか、削除済みなのか、不明なのか?」が曖昧なまま設計が進むと、バグの温床になります。
日本語を扱うアプリを作っていると、突然文字化けが発生したり、大文字・小文字の比較が意図通りに動かなかったりする場面があります。原因は多くの場合、文字コードと照合順序の設定が統一されていないことにあります。
「定期バックアップは設定してある」——それだけで安心していませんか?バックアップは取得するだけでなく、実際に復元できることを事前に確認しておかなければ、いざという場面で役に立ちません。この回では mysqldump を使ったバックアップと復元の基本手順を整理します。
「トランザクションが完了しない」「接続がタイムアウトする」——こうした症状の裏にデッドロックが潜んでいることがあります。デッドロックは完全にゼロにはできませんが、検知の方法と設計上の対策を知っていれば、被害を最小化できます。
在庫管理・予約システム・残高更新——複数のユーザーが同時に同じデータを書き換えようとする場面では、何も対策しなければ後からの更新が前の更新を上書きしてしまいます。これを防ぐのが「悲観ロック」と「楽観ロック」という2つのアプローチです。
トランザクション中にほかのトランザクションが更新したデータを読んでしまう——これがダーティリードやファントムリードと呼ばれる問題です。分離レベルを理解することで、同時実行時に「どの程度の一貫性を保証するか」を意図的に設計できるようになります。
口座Aから500円を引いた瞬間にエラーが発生し、口座Bへの加算が行われなかった——こんな事態を防ぐのがトランザクションです。複数の更新をひとつの「まとまり」として扱い、全部成功するか、全部なかったことにする仕組みです。