第02回: データベースとテーブルの作成 — 最初の定義がすべてを決める
DB設計でよくある失敗は、文字コードを指定せずにテーブルを作り、絵文字が入らなかったり日本語が文字化けしたりすること。あるいはカラムの型を雑に決めて、後から ALTER TABLE で大量データを抱えたまま変更しようとして詰まること。
# User.php
public function init() {
$this->role = 'Architect';
return 'Ready to build';
}
The Latest Craft
View All 
第01回: MySQLの全体像と学習環境 — 「なぜMySQLを学ぶのか」から始めよう
ほぼすべてのWebサービス——SNS・ECサイト・業務システム——は、裏側にデータベースを持っています。その中で世界シェアトップを争うのが MySQL です。
第36回: 本番運用チェックリスト（Laravel版） — リリース前の確認、属人化していませんか？
経験豊富なエンジニアでも、リリース前の確認を頭の中だけで管理していると、プレッシャーや疲労で抜けが発生します。「APPDEBUG=true のまま本番デプロイ」「監視通知先の疎通未確認」——こうしたミスは、チェックリストがあれば防げます。
第35回: 障害対応ランブック作成 — 障害のたびに「どうすればいいか」を考えていませんか？
アラートが飛んできたとき、「まず何を確認すればいいか」「誰に連絡するか」「どこまで判断していいか」——これらが頭の中だけにある状態では、対応者によって復旧時間に大きな差が出ます。
第34回: Queue監視とアラート設計 — 失敗件数だけ見ていて大丈夫ですか？
Queue の失敗件数がゼロでも、処理が遅延していればユーザーへの影響は出ています。メール送信が1時間遅れる、決済処理が詰まっている——こうした「静かな障害」は失敗件数の監視だけでは検出できません。
第33回: 本番DBマイグレーション戦略 — テーブルロックでサービスを止めていませんか？
ALTER TABLE をそのまま実行すると、完了するまでテーブルがロックされます。数分間の書き込み停止が発生し、サービス障害として記録されます。
第32回: ゼロダウンタイムデプロイ基礎 — デプロイのたびにサービスを止めていませんか？
「コードを更新してからマイグレーションを実行する」「マイグレーション後にコードを反映する」——どちらの順番を選ぶかで、デプロイ中の短時間障害が発生するかどうかが変わります。
第31回: レート制限の高度化設計 — 全ユーザーに同じ制限をかけていませんか？
未認証のスクレイパーも、プレミアムプランのユーザーも、同じ制限値が適用されている——こうした設計は、正規ユーザーの体験を損ないながら悪意ある攻撃には十分機能しないことがあります。
第30回: 認証強化（2FA/セッション管理） — パスワードだけで守れていると思っていませんか？
パスワードの使い回しや情報流出は日常的に起きています。「パスワードを設定している」だけでは、現代の認証基準を満たしているとは言えません。
