database - 制約はデータベースにどのような利点をもたらしますか?

Question

この質問は少し「グリーン」側に見えるかもしれませんが、私が遭遇した多くの「エンタープライズ」または「商用」データベースの後、私はこの質問をし始めました. 制約がデータベースにもたらす利点は何ですか? Unique 制約ではなく、Foreign Key 制約について詳しく質問しています。それらはパフォーマンスの向上をもたらしますか、それとも単にデータの整合性を提供しますか?

外部キーのない、または指定された主キーのないリレーショナルデータベースの数にかなり驚いています (フィールドが null でないという制約またはフィールドの一意の制約のみ)。

考え？

score 14 · Accepted Answer

「ただの」データの整合性？あなたはそれが些細なことのように言います。すべてのアプリケーションで、これは重要です。そうです、それはそれを提供します、そしてそれは大きな利点です.

score 6 · Accepted Answer

彼らが提供するのはデータの完全性です。どちらかといえば、パフォーマンスコストがあります (少なくとも非常に小さいものです)。

score 4 · Accepted Answer

それらはパフォーマンスとデータの整合性の両方を提供し、後者は重要なシステムにとって最も重要です。外部キーがなく、すべての整合性がトリガーによって行われているデータベースを見るたびに、私はうんざりします (もしあったとしても)。そして、私はそこにそれらのかなりの数を見ました。

score 3 · Accepted Answer

最初に制約を正しく取得すると仮定すると、次のようになります。

あなたのデータは制約に関して有効です
データベースは、データが制約に関して有効であることを認識しており、データベースのクエリまたは更新時にこれを使用できます (たとえば、ビューのクエリの不要な結合を削除します)。
制約は、データベースの将来のユーザーのために文書化されています
制約違反はできるだけ早く検出されます。後で失敗する無関係なプロセスではありません

score 2 · Accepted Answer

よりシンプルなアプリケーションコード

彼らが提供する素晴らしいことの1つは、アプリケーションコードが行う必要のあるエラーチェックと検証がはるかに少ないことです。これらの2ビットのコードを対比し、何千もの操作を掛けると、大きな成果が得られることがわかります。

get department number for employee  # it's good coz of constraints
do something with department number

対。

get department number for employee
if department number is empty
    ...
else if department number not in list of good department numbers
    ....
else
    do something with department number

もちろん、制約を無視する人は、とにかくコード検証に多くの努力を払わないでしょう...：-/

ああ、データの制約が変更された場合、それはデータベース構成の問題であり、コード変更の問題ではありません。

score 2 · Accepted Answer

データは資産です。多くの教科書にはそう書かれています。

しかし、それは実際には間違っています。むしろ、「正しいデータは資産であり、誤ったデータは負債である」と言うべきです。

また、データベースの制約により、データが正しいという最高の保証が得られます。

score 2 · Accepted Answer

必要な制約はすべてデータベースにある必要があります。外部キー制約により、使用できないデータが防止されます。役に立たないデータベースが必要でない限り、それらは必須です。外部キーは削除と更新のパフォーマンスを低下させる可能性がありますが、問題ありません。削除を行うのにもう少し時間がかかるか (または、システムに注文があるため、この人物を削除しないようにアプリケーションに指示するか)、それともユーザーを削除するがデータは削除しない方がよいでしょうか? 外部キーがないと、データのクエリで予期せぬ、しばしば深刻な問題が発生する可能性があります。たとえば、コストレポートは関連データを持つすべてのテーブルに依存する場合があり、1 つ以上のテーブルに結合するものがなく、重要なデータを表示できない場合があります。

一意の制約は、まともなデータベースの要件でもあります。フィールドまたはフィールドのグループが一意でなければならない場合、これをデータベースレベルで定義しないと、修正が非常に困難なデータの問題が発生します。

他の制約については言及していませんが、言及する必要があります。テーブル内のすべてのデータに常に適用する必要があるビジネスルールは、データ型 ('02\31\2009' を有効な日付として受け入れない datatime データ型など)、制約 (たとえば、フィールドが 100 を超える値を持つことを許可しないもの) またはトリガーを介してロジックが非常に複雑で、通常の制約では処理できない場合。(何をしているのかわからないとトリガーを書くのは難しいので、これほど複雑なロジックがある場合は、チームにデータベースの専門家がいるとよいでしょう。) 順序は重要です。データ型が最初の選択肢で、次に制約が続き、最後の選択肢としてトリガーが続きます。

score 2 · Accepted Answer

リレーショナル理論では、一貫性のないデータを許容するデータベースは、実際にはリレーショナルデータベースではありません。データベースを「リレーショナル」に保つには、データの整合性と一貫性のために外部キーが必要です。つまり、データベースの論理モデルは常に正しいです。

実際には、通常、外部キーを定義して、関係が有効であることを DB エンジンに処理させる方が簡単です。その他のオプションは次のとおりです。

なし - ある時点でデータが破損することを保証
DB トリガー - 通常は遅くなり、パフォーマンスが低下します。
アプリケーションコード - 適切なコードを呼び出すのを忘れたり、別のアプリケーションがデータベースにアクセスしたりすると、最終的に問題が発生します。

score 2 · Accepted Answer

一部の DBMS (Oracle など)では、オプティマイザーが制約を使用してデータの構造に関する知識を得ることができるため、制約によってクエリのパフォーマンスが実際に向上する場合があります。いくつかの例については、この Oracle Magazine の記事を参照してください。

score 1 · Accepted Answer

「ああ、データの制約が変更された場合、それはデータベース構成の問題であり、コード変更の問題ではありません。」

それが設計から消える制約でない限り。その場合、コードへの影響は間違いなくあります。これは、削除された制約が存在することに依存するコードが記述されている可能性があるためです。

宣言された制約を「緩める」または「削除する」ときは、これを常に考慮に入れる必要があります。

それ以外は、もちろんあなたは完全に正しいです。

score 1 · Accepted Answer

共有データベースを使用して複数のアプリケーションを統合する場合、整合性制約は特に重要です。

単一のアプリケーションのコードでデータの整合性を適切に管理できる場合があります (そうしない場合でも、少なくとも壊れたデータはそのアプリケーションにのみ影響します) が、複数のアプリケーションでは複雑になります (少なくとも冗長です)。

database - 制約はデータベースにどのような利点をもたらしますか?

11 に答える 11

Related

Reference