DB設計の失敗パターンと改善事例 ― 現場でよく踏む地雷とその外し方
アプリケーションの寿命は、DB設計の質にかなり左右されます。コードはリファクタリングで直せますが、テーブル設計の失敗は本番データを抱えたまま直すことになるため、修正コストが桁違いに高くなります。
Reactのカスタムフック設計パターン集
Reactのカスタムフックは「状態を持ったロジックの再利用」を実現する仕組みです。しかし書き方の指針がないまま切り出すと、「ただ関数に分けただけ」で終わり、再利用性も可読性も上がらないことがあります。
主キー設計入門 — AUTO_INCREMENT と UUID をどう選ぶか
テーブルを作るときに必ず決めるのが「主キー（Primary Key）をどう採番するか」です。最も一般的な選択肢は次の2つです。
パブリック/プライベートサブネットの設計と使い分け
AWS で VPC を設計するとき、最初に迷うのが「サブネットをどう分けるか」です。とくに パブリックサブネット と プライベートサブネット の違いと使い分けは、セキュリティにもコストにも直結する基本設計です。この記事では、両者の違いを「ル…
パスワードを持たないログイン設計：「コードがあれば通す、無ければ作る」を安全に実装する
ある子ども向けアミューズメント系システムの案件で、通常とはかなり毛色の違う認証要件に出会いました。
NFC来店・ポイント・承認フローを支える飲食店アプリのDB設計 — 100テーブル超を破綻させない5つの勘所
飲食店発見・来店ポイント系アプリのバックエンド設計に携わり、100テーブルを超えるスキーマを扱いました。「ユーザーが店を探す → NFCタグをスキャンして来店 → ポイントが貯まる → 投稿・応援・スタンプラリー」という体験を支えるデータモ…
計測データの時系列グラフAPIを「期間窓ごとに欠損ゼロ」で返す設計
計測機器向けのSaaS案件で、測定値の推移を「1ヶ月 / 3ヶ月 / 半年 / 1年」で切り替える折れ線グラフのAPIを担当しました。一見「期間で集計して返すだけ」ですが、実運用に載せると「測定が無い期間をどう扱うか」が最大の設計判断になり…
Reactのコンポーネント設計原則 ― 入門から実務で迷わないための指針
Reactを書き始めると、まず動くものは作れます。しかしプロジェクトが育つにつれ「このコンポーネント、どこまで責務を持たせるべきか」「propsが増えすぎて扱いづらい」「状態をどこに置けばいいか分からない」といった悩みに必ずぶつかります。
Django でクリーンアーキテクチャを導入する（全体設計編）
Django は「Fat Model / Fat View」になりやすいフレームワークです。ORM が強力で、ビジネスロジックをどこにでも書けてしまうからです。小規模なうちは問題ありませんが、ドメインが複雑化すると「この計算ロジックはどこに…
テーブル命名規約 — プレフィックスで種別を明示する設計
テーブルが数十を超えたあたりから、スキーマは「一覧を眺めただけでは構造がわからない」状態になっていきます。マスタなのかトランザクションなのか、それとも中間テーブルなのか。名前だけでは判別できず、毎回 DDL を開いて確認するという状況は珍し…