Supabase だけでバリデーションできる CHECK 制約が便利

もはや、Supabase の布教に近いですけど、最近、私はバックエンドの知識が全くない状態で Supabase を使ってプロジェクトを構築しています。

そして、特に「いいね」と感じたのはこの CHECK 制約の便利さです。

フロントエンドの開発者でも簡単にデータベース側でバリデーションを設定できて、非常に助かりました。

CHECK 制約 とは

CHECK 制約は、データベースのテーブルに挿入または更新するデータが特定の条件を満たすことを強制する制約です。指定された条件を満たさないデータは挿入または更新が拒否されます。

アプリケーションレベルでのバリデーションコードを書く手間を省きますし、データの一貫性を保つことができます。

製品価格を必ず正数にする

例えば、製品価格が常に正の数であることを保証したい場合、Supabase の GUI からでも SQL エディターからでも簡単に設定が可能です。

GUI を使う場合: Supabase のカラムを右クリックし、Constraints の CHECK Constraint フィールドに以下の条件式を指定します。

SQL エディターを使う場合: 以下の SQL を実行します。

このようにして、製品の価格が常に正数であることを保証できます。参考までに、タイラーさんの動画が役立ちます。

文字数を制限する

次に、name カラムの文字数を制限する場合です。例えば、name を 2 文字以上、30 文字以下にするための CHECK 制約を追加するには以下のようにします。

GUI の場合: CHECK Constraint フィールドに次の条件式を入力します。

SQL エディターを使う場合:

CHECK 制約を利用することで、データベース自体にバリデーションを持たせることができ、アプリケーションからのデータ入力に制限を設けることができます。詳細については PostgreSQL のドキュメント をご参照ください。

エラーハンドリング

データが CHECK 制約に違反した場合、データベースからエラーメッセージが返されます。

Supabase では、error.message を通じてこのエラーメッセージを取得することができ、フロントエンドでユーザーに適切なエラーを表示するのに役立ちます。

以下は、CHECK 制約違反に基づくエラーメッセージの例です。

また、エラーメッセージの内容に応じて条件分岐を行い、ユーザーにわかりやすいメッセージを返すこともできます。

このように、エラーハンドリングを行うことでユーザーにとって使いやすい UI を実現できます。

他のバリデーションの例

CHECK 制約は非常に柔軟で、他にもさまざまなバリデーションに活用できます。例えば：

日付の範囲チェック:

これにより、event_date が過去の日付でないことを保証できます。

特定の文字列のみ許可する: 例えば、status カラムが 'active' か 'inactive' のみ許可されるようにするには、

おわりに

Supabase の CHECK 制約を活用することで、簡単にデータの一貫性を保ちながら、コードの複雑さを減らすことができます。特にフロントエンドの開発者にとっては、サーバーサイドのバリデーションを手軽に導入できるという点で、大きなメリットがあります。これから Supabase を使ったプロジェクトを検討している方は、ぜひ試してみてください。