問題はデータの質に対する責任についてだと思います。
答えは、システムの見方によって異なります。
データベースをアプリケーションとは別の独立した独立した自律型サービスと見なす場合、データベースには、データベースに含まれるデータの一貫性と品質を保証する責任があります。基本的に、そのデータベースは別のアプリケーションで使用できるため、同じ一貫性と品質の動作を持つ2番目のアプリケーションに依存することはできません。このような状況では、APIと自律動作を公開するようにデータベースを設計する必要があります。このビューには少なくとも2つのアプリケーションがあり、1つはデータベースであり、もう1つはそれを使用するアプリケーションです。
逆に、データベースは、アプリケーションの直接かつ完全な制御下にある複雑な形式のファイルと考えることができます。この意味で、データベースは純粋なシリアル化およびドキュメントナビゲーションツールとして機能します。クエリをサポートする高度な動作とドキュメントのメンテナンス(JSONやXMLツールのような)を提供する場合がありますが、(ほとんどのファイルストリームのように)必要はありません。この場合、ファイル内で正しい形式とコンテンツを維持するのはプログラムの責任です。このビューには1つのアプリケーションがあります。
どちらのビューでも、次の質問は、データベースをファンシーファイルとして、または個別のサービスとして使用する方法です。これは次の方法で実現できます。
- データベースプラットフォームがテーブル/ビュー/ストアドプロシージャ/トリガー/などの形式で提供するツールを使用する...
- すべてのクライアントがデータベースにアクセスするために使用する必要があるサービス内にデータベース自体をラップする
- データにアクセスするためにすべてのクライアントが使用する必要があるライブラリにデータベースをラップします。
それぞれに独自の長所/短所があり、システムが動作する環境のアーキテクチャ上の制約に依存します。
どちらのビューを使用するかに関係なく、境界でデータを検証することは常にコストがかかります。
- ユーザーが入力するUIのフィールドを検証する
- クライアントを離れる前にネットワーク/ APIリクエストを検証する
- 何かを行う前に、サーバーでネットワーク/ APIリクエストを検証する
- ビジネスルールに渡されるデータを検証する
- 永続化する前にデータを検証する
- 永続性から取得した後にデータを検証する
- などなど
各境界でどの程度の検証が保証されるかは、検証を行わないことがどれほど危険かによって異なります。
- 2つの数値を掛け合わせる?
- 指定されたメモリ位置でプロシージャを呼び出しますか?
- そのメモリ位置には何がありますか?
- オブジェクトが存在しない場合、または状態が悪い場合はどうなりますか?
- 漢字を含む文字列に正規表現を使用していますか?
- 正規表現モジュールはユニコードを処理できますか?
- 正規表現はユニコードを処理できますか?
However, why not perform validation of data on the application side before storing them into the database?
まあ、これら2つは相互に排他的ではありません。両側で異なるものを検証する可能性があります。アプリケーション側の検証はビジネス中心ですが、データベースの検証はよりデータ中心です。いくつかの異なるアプリケーションによって供給されるデータベースを考えてください。