7
データベースの制約はどうなりましたか？
RDBMSのデータベースモデルを確認すると、通常、PK / FK以外の制約がほとんどまたはまったくないことに驚かされます。たとえば、パーセンテージは多くの場合型の列に格納されますがint（tinyintより適切です）CHECK、値を0..100の範囲に制限する制約はありません。同様にSE.SEでも、チェック制約を示唆する回答は、データベースが制約の間違った場所であることを示唆するコメントをしばしば受け取ります。 制約を実装しないという決定について尋ねると、チームメンバーは次のように応答します。 そのような機能がお気に入りのデータベースに存在することすら知らないということです。ORMのみを使用するプログラマからは理解できますが、特定のRDBMSで5年以上の経験があると主張するDBAからはほとんど理解できません。 または、アプリケーションレベルでそのような制約を強制し、データベースでそれらのルールを複製することは、SSOTに違反して、良いアイデアではありません。 最近では、外部キーさえ使用されないプロジェクトが増えています。同様に、ユーザーが参照整合性をあまり気にせず、アプリケーションにそれを処理させることを示す、SE.SEに関するいくつかのコメントを見ました。 FKを使用しない選択についてチームに尋ねると、次のように伝えます。 たとえば、他のテーブルで参照されている要素を削除する必要がある場合は、PITAです。 NoSQLは揺れ動き、外部キーはありません。したがって、RDBMSではそれらは必要ありません。 パフォーマンスの点では大したことではありません（コンテキストは通常、小さなデータセットで動作する小さなイントラネットWebアプリケーションですので、実際にはインデックスでも大したことはありません。特定のクエリのパフォーマンスが1.5 。〜20ミリ秒） アプリケーション自体を見ると、次の2つのパターンに体系的に気付きます。 アプリケーションは、データベースに送信する前にデータを適切にサニタイズしてチェックします。たとえば102、アプリケーションを介して値をパーセンテージとして保存する方法はありません。 アプリケーションは、データベースからのすべてのデータが完全に有効であると想定しています。つまり102、パーセンテージで表示された場合、どこかでクラッシュするか、単にユーザーにそのまま表示され、奇妙な状況になります。 クエリの99％以上が1つのアプリケーションによって実行されますが、時間が経つにつれて、スクリプトが表示され始めます。必要に応じてスクリプトを手動で実行するか、cronジョブを実行します。一部のデータ操作も、データベース自体で手動で実行されます。スクリプトと手動SQLクエリの両方に、無効な値が導入されるリスクが高くなります。 そしてここに私の質問が来ます： チェック制約なしで、最終的には外部キーなしでもリレーショナルデータベースをモデル化する理由は何ですか？ 価値のあることについては、この質問と私が受け取った回答（特にThomas Kilianとの興味深い議論）により、データベースの制約についての結論を書いた記事を書くことになりました。