データ検証を完全にデータベースエンジンの制約に委任するのは良い習慣ですか？
アプリケーションからのデータを検証しても、別のソフトウェア（おそらく別のチームによって別の言語で書かれたもの）からの無効な挿入を防ぐことはできません。データベース制約を使用すると、無効な入力データについて心配する必要があるポイントを減らすことができます。
データベースとアプリケーションの両方で検証を行うと、アプリケーションの数を知っている人のコードを更新する必要があり、人的エラーの可能性が高くなるため、メンテナンスが面倒になります。
自由ソフトウェアプロジェクトのコードを見ると、これがあまり行われていないようです。
入力時に検証します。データベースに配置する前に、再度検証してください。また、不正な入力を防ぐためにデータベースの制約があります。それにもかかわらず、悪いデータはデータベースに侵入するので、使用するときにもう一度検証してください。
一部のWebアプリは、Javascriptを使用してフォーム内ですべての検証を行ったため、またはさらに悪いことに、それを回避する方法を見つけたため、毎日ハッキングされているようです。あなたはそれを防ぐ必要があります。
パラノイド？自分？いいえ、経験したばかりです。
可能であれば、検証ルールをデータベースで指定し、それらのルールをフロントエンドにバブルアップさせるフレームワークを使用または作成することをお勧めします。ASP.NET Dynamic Data はこれに役立ち、さらに簡単にする商用ライブラリがいくつかあります。
これは、単純な入力検証 (数値や日付など) と、外部キーによって制約されるような関連データの両方に対して実行できます。
要約すると、1 つの場所 (ほとんどの場合データベース) でルールを定義し、それらのルールを適用する他のレイヤーにコードを配置するという考え方です。
ロジックをデータベースに任せることの欠点は、その特定のサーバーの負荷が増えることです。Webサーバーとアプリケーションサーバーは比較的簡単に拡張できますが、データベースには特別な技術が必要です。原則として、できるだけ多くの計算ロジックをアプリケーション層に配置し、データベースとの対話を可能な限り単純に保つことをお勧めします。
そうは言っても、アプリケーションがそのような重いスケーラビリティの問題について心配する必要がない可能性があります。データベースサーバーの負荷が当面問題にならないことが確実な場合は、先に進んでデータベースに制約を課します。これにより、検証ロジックを中央の場所に保持することで、システム全体の構成と単純さが向上することは間違いありません。
入力による SQL インジェクション以外にも懸念事項があります。ユーザー入力を受け入れるときは常に、可能な限り最も防御的なスタンスを取る必要があります。たとえば、ユーザーが画像へのリンクをテキスト ボックスに入力できる可能性がありますが、これは実際には何か厄介なものを実行する PHP スクリプトです。
アプリケーションを適切に設計すれば、すべての入力を面倒にチェックする必要はありません。たとえば、ほとんどの作業を処理する Forms API と、ほぼ同じ処理を行うデータベース レイヤーを使用できます。
これは、脆弱性の基本的なチェックに適したリソースです。
ユーザーやアプリケーションに意味のある検証を提供するには、データがデータベースに届くまでには遅すぎます。データベースがすべての検証を実行するのは望ましくありません。これは処理がかなり遅くなるからです。また、データベースはロジックを明確に表現しません。同様に、成長するにつれて、データベース トランザクションを補完するために、より多くのアプリケーション レベルのトランザクションを作成することになります。
クエリが失敗したときに何が起こるかによっては、それは潜在的に悪い習慣だと思います。たとえば、データベースがアプリケーションによってインテリジェントに処理されたエラーをスローする可能性がある場合は、問題がない可能性があります。
一方、アプリに検証を行わない場合、悪いデータはないかもしれませんが、保存されないものを入力したとユーザーに思わせる可能性があります。
他の目標を損なうことなく、データベースの最後でできるだけ多くのデータ検証を実装します。たとえば、速度が問題になる場合は、外部キーなどを使用しないことを検討してください。さらに、一部のデータ検証は、電子メールアドレスに有効なドメインがあることを確認するなど、アプリケーション側でのみ実行できます。
データベースからデータ検証を行うことのもう1つの欠点は、すべての場合に同じ方法で検証しないことが多いことです。実際、アプリケーションロジック（ユーザーロール）に依存することが多く、検証を完全にバイパスしたい場合もあります（cronジョブとメンテナンススクリプト）。
データベースではなくアプリケーションで検証を行うとうまくいくことがわかりました。もちろん、すべてのやり取りはアプリケーションを経由する必要があります。データを操作する他のアプリケーションがある場合、アプリケーションは何らかの API (できれば REST) をサポートする必要があります。
使い方次第で正解は一つではないと思います。
データベースのパフォーマンスがボトルネックになる可能性がある非常に頻繁に使用されるシステムを使用する場合は、検証の責任を、複数のサーバーでスケーリングしやすいフロントエンドに移すことをお勧めします。
データベースと対話する複数のアプリケーションがある場合、複数のアプリケーション間で検証ルールを複製して維持したくない場合があるため、データベースの方が適している可能性があります。
ユーザーがレコードを保存しようとしたときに検証の警告を表示するだけでなく、より洗練された入力画面が必要になる場合があります。データが入力されてフォーカスが失われた後にフィールドを検証する必要があるかもしれません。または、ユーザーが入力しても、検証が失敗/合格するとフォントの色が変更されます。
また、制約に関連するのは、疑わしいデータの警告です。私のアプリケーションでは、データベースに厳しい制約があります (たとえば、誰かが生年月日より前に仕事を始めることはできません)。 -古い仕事を始める）。