アプリケーションのモデル/プレゼンテーション層に必要なすべてのビジネスルールがあり、それらが正常に機能すると仮定します。私の質問は、冗長なビジネスルール（つまり、2つの日付のスパンが他の既存のスパンと重複できない）をSQLServerなどのリポジトリで使用する必要があるかどうかの1つです。
このルールを適用する制約をSQLServerに追加する必要がありますか？一方では、アプリケーションをバイパスするときに、だれか（DBAを含む）が不注意にビジネスルールを破ることを防ぎます。さらに、プライマリキーと外部キーを介してリポジトリにいくつかの形式のビジネスルールがすでにあります。一方、複製されたルールは、開発と維持に追加の時間を必要とします。
この質問は多くの異なるテクノロジーにまたがっているので、私は意図的にタグを一般的にしました。
データに関心がある場合は、必要なルールを他の場所より優先してそこに配置します。データはアプリケーション以外の多くの場所から影響を受けます。ビジネス層だけにルールを配置するのはため息が出るほどであり、深刻なデータ整合性の問題につながります。修正しようとするのは恐ろしいことです。データに関するルールは、データベースに属します。
一般に、手作業で複数の場所でビジネス ルールを管理することは非常に困難です。
私はいくつかのプロジェクトでコード生成をうまく利用して、要件モデルからいくつかのタイプのルールを生成しました。たとえば、「名は 50 文字を超えてはならない」という要件があるとします。その要件を構造化された方法で UML でモデル化し、入力を 50 文字に制限する UI コード、同じ制限を適用するビジネス ロジック (UI を決して信頼しないでください!)、および列幅を指定する DDL/ORM マッピング ファイルを生成します。 DB。
同じ考え方を拡張して、より複雑なルールをモデル化し、アプリケーションの各レイヤーに適切な施行コードを生成することができます。
ビジネスルールまたはデータ整合性ルール?
私の経験では (主に大企業です。ここではソフトウェア ハウスやホビー ショップの話ではありません)、データベースはアプリケーションより長持ちします。そして最終的には、他のアプリがそれと通信するようになります。そして、(どんな種類の) ルールも設定されていない場合、誰かが、どこかでデータベースを壊します。
あなたはそれを自分で言いました...バックドアでビジネスルールを強制するもの（つまり、DBAのポークデータ）。これが起こることを恐れているなら、代償を払ってください。そうでない場合は、オフのままにして、他の場所で適用されるルールが冗長にならないようにします。
アプリケーションによって異なります - データベースに依存しないことを意図している場合は、ロジックをアプリケーション コードに保持してください。それ以外の場合、ビジネス ルールはデータベースに適しています。