MySQLのサポートエンジニア
RDBにおけるバリデーションってなんだろう
リレーショナルモデルにバリデーションはない
ないが、constraintはある(制約)
constraint
評価した結果真となる条件式
- type constraint
- データ型が満たすべき条件 ドメインの定義
- database constraint
- データベース内のデータが満たすべき条件
- 外部キーはこの一種
ドメイン
- データ型のことをドメインという
- 属性(カラム)が取りうる値の集合
- 属性の値は、ドメインの要素の一つである
- 属性の値は予めドメインに登録されている
- そうなるようにドメインを設計する
どうやってドメインを表現するか
- ドメインを集合として表現することは不可能に近い
- 文字列で表現するデータが難しい
- データサイズが大きい
ドメインの要素数が膨大になる
列挙できるがデータサイズが大きいもの
- 未知の値が多すぎて対処できない
- フリーダムすぎるもの
→これらをドメインとして表現するのは不可能
妥協案 ドメインを制約で表現
- SQL上で使用できるツール
- check制約
- create type
- トリガー
テーブル+外部キー制約
制約で、テーブルに格納するデータをフィルタリングする
データの危険性を鑑み、バリデーションが必要なのでは?
DBの出力→アプリへの入力
- アプリケーションへ入力されたデータは適切にバリデーションしましょう
- RDB側でバリデーションは必要なくって、アプリでやってくれ
- RDBで出来るのは制約
ドメインの設計は超重要
- 正しく設計すれば、アプリケーションによるバリデーションの手間が軽減される
- 数値は数値型を
- check制約で取りうる値の範囲を絞り込む
- フリーダムなデータはアプリ側で確実にバリデーションを
本当に正しい値か
- 運用設計は重要
- データが正しいかどうかを確認するのはアプリケーションの運用者
- ホワイトリスト方式でドメインを実装しても、この問いは完全には消え去らない
- ユーザーのオペミスは十分にありうる
SQL≠リレーショナルモデル
この２つはちゃんと対応していない
- リレーショナルモデル 集合論 すべて集合 集合にもとづく演算
- SQL データベース操作言語 selectに盛り込まれたリレーション演算 モデル以外のデータの扱いおよび操作も可能
リレーショナルモデルであつかえないデータがある
- 現実世界のアプリケーション
- リレーショナルモデルに適合するデータとそうでないデータが入り乱れている
- リレーショナルモデルには定石がある
- 無理に実践すべきではない
RDBにおける制約とバリデーション
- 制約: リレーショナルモデルの世界
- バリデーション: リレーショナルモデルの外側の世界
- アプリケーションと同じようにバリデーションが必要
プロシージャ内でprepareするべからず
まとめ
- RDBにあるのは制約であってバリデーションではない
- RDBまわりでバリデーションが必要なところ
- アプリケーションへの入力
- バリデーションはアプリケーション側への課題
- リレーショナルモデルに沿わないデータやロジック
