DB制約 NOT NULL/UNIQUE/FOREIGN KEY を実演で理解する

はじめに

データベース（リレーショナルデータベース）でよく利用する制約についての話です。

よく使う制約

NOT NULL（ノット・ヌル制約）

「カラムの中身がNULLになってはいけない」という制約です。必ず内容が入っていることを保証できるので、プログラミングを間違えた時にもDBの方で「このデータが入っていないからちゃんとコード書くこと！」という風に伝えてくれます。

NULLカラムが増えてくるとNULLを意識しないといけないシーンが増えて、プログラミングする際に気をつけないといけない事が増えます。NULLチェックをしないで済むようにすると、不具合が減らせることはある程度コードを書いた人には納得感があると思います。

UNIQUE（ユニーク制約）

「同じ値になるものがあってはならない」という制約です。他のデータと被らないことを保証できます。ID的な扱いになるものには必須ですね。ここでは紹介しませんでしたが、複数のカラムを会わせてUNIQUEする、複合ユニーク制約というものもあります。

FOREIGN KEY（外部キー制約）

「別のテーブルのあるカラムの値と一致しないといけない」という制約です。大抵は他のテーブルで利用されているIDとの関係を示して、適切なリレーションを保証するために使います。

ここで紹介したエラーでよく見る英単語

• duplicated: 「重複している」ことを示します。
• violate: 「違反している」ことを示します。

エラーは助けてくれている。怖くない。

キッチリ制約を入れていくと、少しでも違反するとエラーになってしまうので怖くなってしまう人もいるかもしれませんが、想定外のデータがデータベースに入っている状態があとで判明する方が余程面倒なことになりますので、最低でも上記のような制約は入れておくと救われる事が多いでしょう。

また、チームや開発メンバーによって、どの程度まで制約にこだわるかが違う場合があるので、一緒に開発する人々と雰囲気を合わせておくのも大事かもしれません。

プログラミングのコードで守れば良いのか

「プログラミングのコードで値をチェックしているから想定外の値が入ることはないのでは？」という疑問を持つ方もいる様子ですが、実際のシステムでは並行して多数のアクセスが起こります。そうするとコードでのチェックを終えた後、保存がなされる直前に別の処理が割り込んで情報を書き込んでしまうなどして想定外の値が入ってしまうという状況はよく起こります。

その為、最後の砦となるDBの制約は入れておいた方が良い、という話でした。