コードではなくデータベースに制約が適用されるのはなぜですか？
データベースに制約が適用されるのはなぜですか？それをコードに入れることはより柔軟ではないでしょうか？ データベースの実装に関する初心者向けの本を読んでいるので、これを初心者として尋ねています。このエンティティモデルを含むデータベースを設計したとしましょう。 entity type | sub-types ----------------+-------------------------------------------- Person | Employee, Student, ... Student | Graduate, Undergraduate, ... Employee | Teacher, Administrator, ... 現在の制約： システムの登録者は、学生または従業員のみです。 個人エンティティには社会的番号の一意性が必要です。これは、すべての個人が一意の一意の名前（別名、十分に優れた主キー）のみを保持していることを前提としています。（＃1を参照） 後で番号1を削除することにしました。ある日、大学がTeacher（Employeeサブタイプ）もStudent自由時間でコースを取ると決定した場合、数千、数百万、数十億のデータベース設計を変更するのははるかに困難です。コードのロジックを変更するだけでなく、数十億のエントリ：学生と従業員の両方として個人を登録することを許可しなかった部分のみ。 （ありそうもないことですが、今のところ他に何も考えられません。 どうやらそれは可能です）。 コードではなくデータベース設計でビジネスルールを重視するのはなぜですか？ ＃1：7年後のメモ、実際の例： 私は、ミスのために発行されたSSNが複製された政府を見ました：複数の人々、同じSSN。元のDBの設計者は、この一意性制約をデータベースに適用しないという間違いを間違いなく犯しました。（そして元のアプリケーションのバグ？共有データベースを使用している複数のアプリケーションが制約をどこに置き、チェックし、強制することに同意しませんか？...）。 このバグは、今後何年もの間、システムとその後に開発されたすべてのシステムで存続し、元のシステムのデータベースに依存します。ここで答えを読んで、可能な限り多くの制約をデータベースに賢明に（盲目的にではなく）適用して、現実の物理的な世界をできるだけうまく表現することを学びました。