BLOGサブスレッドの日常

2026.06.27

2026年6月のサブスレッド勉強会

chao

はじめに

しみずです。どうぞよろしく。

遅くなってしまいましたが、今回は、6月12日(金) に開催された6月のサブスレッド勉強会についてご紹介します。

今回の勉強会は PostgreSQL のお話です。
外部講師として、Have Fun Tech の曽根さんにお越しいただきました！
勉強会ではデータ型や検索のお話もありましたが、今回は私が個人的に「もっと活用していこう」と感じた「制約」の話を中心に、紹介したいと思います。

DB制約は、「最後の砦」である

開発をしていると、「バリデーションはフロントエンドやバックエンドで十分ではないか？」という議論になることがあります。
もちろん、ユーザー体験（UX）やビジネスロジックの担保は、フロントエンド、バックエンドそれぞれのレイヤーで行うべきですが、最終的に正しいデータだけを保存する「最後の砦」として、DBの制約は欠かせない存在という話がありました。

特に最近は JSONB のような柔軟な型を使うことも増えてきましたが、何でもJSONBに頼ってしまうと、以下のような弊害が生まれることもあります。

  • 外部キー制約が張れず、データの整合性が崩れやすくなる
  • 必須チェック（NOT NULL）が難しくなる
  • 制約が散らばり、管理が複雑化する

こういった弊害があるため、「業務上で重要なデータは、できるだけカラムとして切り出して、しっかり制約をかける」という基本の大切さを改めて痛感しました。

「制約」の種類

一般的な NOT NULL や UNIQUE、FOREIGN KEY は普段からよく利用しますが、今回の勉強会では、より高度な制約についても触れられていました。

1. CHECK制約

特定の条件を満たす値だけを許容する CHECK 制約は、これまであまり積極的には使っていませんでした。
ですが、これを知っておくことで「ステータスの範囲制限」や「特定フォーマットの強制」をDBレベルで安全に担保できます。
今後はもっと意識的に採用していきたい機能だと感じました。

2. 排他制約

排他制約は、データの重複や衝突を防ぐ仕組みです。

  • 予約のダブルブッキング防止
  • チケット購入時の座席重複防止

といったケースでの利用が想定されます。
アプリケーションレベルで防ぎ切ることが難しいチェック処理を、DBの仕組みで確実に防げるのは大きなメリットだと感じました。

3. 条件付きの制約

「特定の条件（WHERE句）を満たすデータだけ」に対して制約を適用することができるという話です。
排他制約と組み合わせることで
「キャンセルされていないデータだけ期間の重複禁止にする」
といった、現実に有り得そうな業務ロジックに即した制約をかけることができます。
（PostgreSQLの排他制約にWHERE句を組み合わせるなど）

おわりに

今回の勉強会を通じて、制約は単なる制限ではなく、「DBが担保する最後の品質保証」であると強く感じました。
制約を適切に設定していると、「そのデータは絶対に入らない」という強い安心感が持てますし、結果としてチーム全体の開発効率やコードの信頼性向上にもつながるはずです。
DB制約をもっと使っていこうと感じた一日でした。明日からの設計に活かしていければと思います。

なお、今回お話いただいた内容については、曽根さんのブログにて、圧倒的ボリュームでまとめていただいています。
是非、ご覧ください！
Djangoで便利なPostgreSQLの活用方法

サブスレッド勉強会は毎月開催しております。
このように実業務に直結する技術テーマから、日々の生活に役立つ知識まで、幅広いテーマを扱っています。

ご興味のある方は、お問い合わせフォームや最寄りの弊社スタッフまで、お気軽にお声がけください！

今回は勉強会後に、みんなでバーベキューを楽しみました！

この記事を書いた人

chao

一覧に戻る