マルチサーバーRDBMSまたはアプリケーションはデータベース参照整合性を処理する必要がありますか？

外部キー、制約、デフォルト値などの項目は、データベース管理システム（この場合はMS SQL 2005）またはアプリケーションによって処理される必要がありますか？両側から意見を聞いたことがありますが、どちらに行くべきかは正直わかりません。

複数のサーバー/データベースにまたがる可能性があり、リンクサーバー間で外部キーを使用できるとは思いません。それに加えて、データベース設計にはいくつかの循環参照があり、ON UPDATE CASCADEすべてを使用できません。

データベースはMS SQL 2005（おそらく2008）であり、データベースとのすべてのやり取りはアプリケーションを介して行われる必要があります。

DBがアプリケーションの外部で変更される可能性がある場合は、データベース内の制約が必要です。DBが常にアプリケーションのバックエンドに過ぎない場合は、それらを省くことができます。ただし、万が一パフォーマンスの低下がそれほど悪くない場合は、おそらくそれらをそのままにしておきます。（Peoplesoftソフトウェアはこのように機能します-制約はソフトウェアにあり、（私はこれを構成していません）OracleでSYSとしてすべてを実行します。）

そのようなものをアプリケーションで監視し、インテリジェントに反応し、せいぜいデータベースエラーメッセージをユーザーに返さないようにする必要があります。

そして、はい、これは二重のカバレッジですが、それなしでは、おそらく予防可能なデータ破損や悪いユーザーインターフェイスを取得するでしょう。

理想的には、両方。DBに処理させるべきではありませんが、DBが拒否するデータをアプリが思いついた場合、それはランタイムエラーであるため、アプリには少なくとも参照整合性を維持するための専用のコードが必要です。また、DBのSQLで適切な制約を設定することは、クライアント側のコードを設定するよりもはるかに簡単なので、DBでそれを行うと、必要な作業量が大幅に削減されます。

重要な場合は、データベースに処理させます。そうすれば、誰かがアプリケーションの外部のデータベースにアクセスし、矛盾したデータや重複したデータを変更または入力することを心配する必要がありません。高度なアプリケーション固有のもの（「ZZZのアクセスクラスを持つ部門Xのユーザーのみがグループ999に属することを許可する必要がある」など）を除き、通常は「参照」整合性とは呼ばれません。

データベースに入れると言うでしょう。永続的なフレームワークを使用している場合は、キーが自動的に取得されます。

両方とも間違いなく進むべき道です。不正な更新や挿入を防止し、ユーザーに何が間違っているのか、どのように修正するのかを伝えるために、コード内に検証ロジックが必要になります。そして、何かをバックストップするためにそこにデータベースを持っているので、何かが入って検証を実行しなかった場合、それは物事を混乱させないでしょう。

データベースの内容をより高いレベルに維持する必要があります。EG、参照整合性を強制し、おそらくいくつかはnullではありません。ただし、長さや形式を制限することを心配する必要はありません。アプリケーションに完全にレンダリングされるのが最善です。