-1

MSSQLDB内で関係の制約を維持することについてあなたの考えはどうですか。

ASPから.NET環境にシステムを移行しています。これにより、ユーザー/APIからデータベースを抽象化するために機能するビジネスオブジェクトやその他の階層型コーディング手法がもたらされます。新しいアプリケーションには、EntityFrameworkDALの上に明確なAPIがあります。

古いデータベースのアプリケーションDBは大きく、一部のテーブルの目的は、ファイルなどの形式のバイナリデータを含むように変更されます。これらを別々のDBに分割して、での管理を容易にすることを望んでいます。ディスク容量が限られているクライアントサイト。

テーブル間の関係制約を保持することに価値はありますか？

仮定：

  • コードがテストされます
  • 関係が重要な場合、実行はトランザクションの下で実行されます
  • DBへのアクセスはAPIのみを介して行われ、サードパーティによる他のアクセスはサポートされていません。

制約を維持する理由：

  • データ構造を適用します
  • 結合はより高速ですか？
  • クエリプランの支援？

新しい.NETバージョンで制約を削除する理由：

  • API/BIZロジックが親/子などの関係を管理すると想定できます。
  • DBのセクションを他のカタログに隠す機会を減らします（システムはプラグインアーキテクチャを使用して構築されており、ほとんどのテーブルは分離して動作する可能性があります）
  • SQLが制約のINSERT中に追加のチェックを実行する必要があると信じているのは正しいですか？これは、DBの上のAPIがこれを管理している場合は不要な場合がありますか？
4

3 に答える 3

2

はい、リレーショナル制約を維持することをお勧めします。確かに、BLLでそれらを処理する必要がありますが、クエリプランナーがクエリをより効率的に処理するために使用されるため、制約によってパフォーマンスも向上します。

この質問も参照してください：データベース設計で外部キーは本当に必要ですか？

于 2009-04-29T10:27:26.457 に答える
1

制約が「自動的に索引付けされる」という主張はサポートしていません。一意の主キーのみが実行します。ほとんどの場合、FKの列と一致する「子」にインデックスを付けることをお勧めしますが、外部キーはそうではありません。それでも、FKeysをお勧めします

  1. データの整合性を強化します（BLにバグがあり、仕事に失敗したことで何度も噛みました）。
  2. オプティマイザーにデータのパターンに関するより多くの情報を提供します。これにより、実行プランがより適切かつ高速になる可能性があります。

しかし、何よりも、データを単一のデータベースに保持し、それを複数のファイルグループに分割することを考えたことはありますか？複数のDBにまたがる外部キーの煩わしさなしに、より柔軟なディスクスペース管理という目標を達成できます。

于 2009-04-29T10:53:03.400 に答える
1

はい、特別な理由がない限り、テーブルに外部キー制約を設定する必要があります。アプリケーションがテストされたとしても、データベースに書き込むのはそれだけではないかもしれません。FKは、すべてのソースからのデータに参照整合性を適用します。

外部キーは、データベース内の関係の一種の非公式な文書化ツールとしても機能します。FKがデータベースに存在する場合、Visio（またはリバースエンジニアリングをサポートするその他のツール）を使用してスキーマをリバースエンジニアリングし、関係を確認できます。パフォーマンスの名の下にデータベースに外部キーをドロップすることは、ISVがデータベーススキーマをわかりにくくし、より多くのサポート収益をもたらすために使用する一般的な手法です。

特定のパフォーマンス関連の問題を外部キーまで追跡できる場合は、キーを削除する必要がある場合があります。これは、1つまたは2つの特定の大容量テーブルの少数のキーでのみ発生する可能性があります。また、トランザクション量が非常に多いシステムでのみ必要になる可能性があります。データベースに外部キーがまったくないという言い訳はありません。

于 2009-04-29T11:04:57.643 に答える