こんにちは！データベースの世界へようこそ。
普段、データの設計をしていると「これ、間違ったデータが入ると後で地獄を見るよな……」なんてヒヤヒヤすること、よくありますよね。
今日は、そんな「データの門番」として超優秀な、「CHECK制約」という機能についてお話ししようと思います。
「CHECK制約」って、なに？
一言でいうと、「データに対する『お約束』」です。
たとえば、あなたがカフェの注文管理アプリを作っているとしましょう。「コーヒーの価格」を記録する列があるとしますよね。でも、うっかりミスで価格が「マイナス100円」なんて入力されてしまったら……大変です。お店が潰れてしまいますよね。
そんなとき、データベースにこう伝えておくんです。
「ねえ、コーヒーの価格は必ず0円以上にしなきゃダメだよ！」
これがCHECK制約です。データベースがデータを保存する前に、「このデータ、さっきのお約束守ってる？」とチェックして、もし守れていなければ「ダメ！そんな変なデータは受け入れないよ！」と弾いてくれる。これ、すごく安心だと思いませんか？
なぜ「CHECK制約」を使うべきなの？
「そんなの、アプリを作る時にプログラム側でチェックすればいいんじゃない？」と思うかもしれません。確かにそれも正解です。でも、データベース側にも設定しておくことには、2つの大きなメリットがあるんです。
1. どんなルートからでも「嘘」がつけない
アプリを作っていると、管理画面からデータをいじったり、直接データベースを操作したりすることもありますよね。アプリのコードだけでガードしていると、別のルートから変なデータが入ってくるリスクが残ります。でも、データベース自体に制約をかけておけば、どこからアクセスしても、お約束を破ることは絶対にできません。これは最強の守りです。
2. PostgreSQLが「頭」を使ってくれる
ここが実は一番面白いところです。PostgreSQLのクエリプランナ（データの探し方を決める司令塔）は、とても賢いんです。
例えば、「価格が0円以上の商品」という制約があるテーブルに対して、「マイナス500円の商品を探して！」という命令が来たとします。普通のデータベースなら、一生懸命テーブル全体を探しに行こうとします。でも、CHECK制約を知っているPostgreSQLはこう考えます。
「いやいや、そもそもマイナス価格の商品はここには存在しない（お約束で禁止してる）んだから、探すまでもないよね」と。
結果として、無駄な検索をせずに即座に「そんなデータはないよ」と返してくれます。つまり、データを守るだけでなく、検索も速くしてくれるというわけです。一石二鳥ですよね。
実際に書いてみよう
PostgreSQLで書くときは、こんなにシンプルです。
CREATE TABLE menu (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL,
price INT CHECK (price >= 0) — ここでお約束！
);
たったこれだけ。「priceは0以上であること」と一行書くだけで、もうあなたのテーブルは少しだけ賢くなりました。
最後に
最初は「わざわざ設定するの面倒だな」と思うかもしれません。でも、この「ちょっとした手間」をかけるだけで、数ヶ月後のあなたが「データが壊れてない！救われた……！」と泣いて喜ぶ日がきっと来ます。
データベースは、いわばあなたの城を守る騎士です。制約は、その騎士に与える「正しい立ち振る舞い」のルールブック。ぜひ皆さんの設計でも、この「門番」を積極的に配置してあげてくださいね。
また次回の記事でも、データベース設計のちょっとしたコツをお届けします。それでは、良いエンジニアライフを！
コメント