データベースの整合性を強化する

これは、外部キー、チェック制約などを持たせる代わりに、アプリケーションにデータベースの整合性を強制することに意味があるでしょうか？

内部データベースツールを使用してデータベースの整合性を強制しない場合、パフォーマンスの向上はどの程度期待できますか？

実を言うと、データベースに外部キー制約があることでパフォーマンスが大幅に低下することはないだけでなく、パフォーマンスが向上することもわかります。SQL Serverクエリオプティマイザーは、主キーと外部キー、およびその他の種類のデータ制約の概念に基づいて構築されています。これらが適切に実施されている場合、オプティマイザーはそれらを利用してパフォーマンスを向上させることができます。以下に、実際の動作を示す簡単な例を含むブログ投稿を示します。

本当に読み取りよりも多くの挿入があるエッジケースの場合（および更新と削除には読み取りが必要なため、通常は読み取りカウントに追加されます）、パフォーマンスのためにデータから制約を削除することは理にかなっているかもしれません。しかし、圧倒的多数のデータベースは読み取り指向であるため、パフォーマンスを犠牲にしており、パフォーマンスを向上させているわけではありません。

そして、コードですべての作業を行う場合と同様に、複数のアプリに対して複数回行う必要がある場合があるため、一度作成するだけでよいため、データベースでデータの整合性がより適切に処理されるという事実は言及されていませんデータアクセスレイヤーを慎重に設定し、すべてのアプリがdbにアクセスして同じレイヤーを通過する必要があります）。

リレーショナルデータベースシステムを使用している場合、実際に使用しないのはなぜでしょう。リレーショナルデータが必要ない場合は、Hadoopなどを使用してください。

多くのアプリケーション開発者はそう考えています。

データの整合性をアプリケーションコードに委任したい場合は、「このデータベースにヒットするすべてのプログラマーとすべてのアプリケーションが、いつでも完全に適切な状態にする必要がある」と考えてください。

オッズは何ですか？

パフォーマンスが向上したとしても、参照整合性と一般化されたデータ整合性が返されるのに比べると、無視できます。

データベースが無意味なデータストアである時代はもはや過ぎ去りました。RDBMSが提供する力を活用してください。

特にこのような小規模では、パフォーマンスの向上がすべてではありません。しかし、アプリケーションが強制するはずの想定される外部キー関係があることがわかり、それが参照テーブルの主キーではないことが判明した場合、パフォーマンスの向上についてはほとんど気にしません（もしあれば、その詳細については話さないでください）。

十分な量のデータロードを実行している場合は、制約（外部キー、CHECKなど）とインデックスを削除し、後で制約とインデックスを再度有効化/実装するのが一般的です。その検証には時間がかかります。これは、データベース固有のバルクロード構文を使用できないことを前提としています（ロギングの最小化を含む）。

予想されるパフォーマンスの向上の程度を言うことは不可能です-各状況は一意です（データ型、設計など）。本当に知る唯一の方法はテストすることです。

制約が邪魔になる場合がいくつかあります。

1. 単一テーブル継承（STI）を使用する必要がある場合。個人と組織の両方に販売していると想像してください。行が個人または組織のいずれかである単一の「パーティー」テーブルが必要です。STIは、nullであってはならないnull可能フィールドが必要であることを意味します。Class Table Inheritanceはこれを解決しますが、これはいくつかのORMにとってより困難です。たとえば、RubyのActiveRecordはSTIのみをサポートしています。

2. エンティティのドラフトバージョンをサポートする必要がある場合、完全に有効ではない可能性があります。ドラフトをjsonとして保存することもできますが、クライアントで同じ識別子を再利用するのは難しくなります。id= 5で保存され、無効になるように編集され、draftid = 99として自動保存されます。この場合、すべてのフィールドはおそらくnull入力可能にする必要があります。