database - 参照整合性を強制する必要がありますか?

Question

参照整合性を適用しない理由の 1 つは、パフォーマンスです。Db は関係に対してすべての更新を検証する必要があるため、処理が遅くなるだけですが、強制する場合としない場合のその他の長所と短所は何ですか?

とにかく関係はビジネスロジックレイヤーで維持されるため、dbがそれを行うためにそれらを冗長にするだけです。それについてどう思いますか。

score 26 · Accepted Answer

データベースはデータを担当します。それでおしまい。限目。

データベースで参照整合性が行われていない場合、それは整合性ではありません。人々が悪いことをしないと信じているだけです。その場合、データをパスワードで保護することについても心配する必要はありません:-)

完璧に作成され、バグのないビジネス層にもかかわらず、誰かが独自の JDBC 接続クライアントを作成してデータを完全に台無しにすることはないと誰が言いますか (おそらくバグがなくなるという事実は、完全に別の問題です)。、DBがそれ自体を保護する必要があることを義務付けています）。

score 10 · Accepted Answer

まず第一に、それを本当に正しく動作させることはほとんど不可能です。正常に動作する可能性を少しでも確保するには、多くのカスケード変更をトランザクションとしてラップする必要があります。これにより、データベースの一部を変更している間に同期がずれることはありませんが、依存する他の部分をまだ更新しています。最初。これは、単純でビジネスロジックのみを認識する必要があるコードが、突然、あらゆる種類の同時実行の問題について認識する必要があることを意味します。

第二に、それを機能させ続けることを期待することはほとんど不可能です。誰かがビジネスロジックに触れるたびに、それらの並行性の問題に再び対処する必要があります。

第 3 に、これは参照整合性の理解を困難にします。将来、誰かがデータベース構造について知りたい場合、ビジネスロジックからリバースエンジニアリングを行う必要があります。それはデータベースにあるため、別のものであるため、見なければならないのは参照整合性のみを扱い、関連のないあらゆる種類の問題を扱うわけではありません。（たとえば）特定のフィールドへの変更がトリガーされるものを示すロジックの直接チェーンがあります。少なくともかなりの数のデータベースでは、そのロジックを自動的に抽出して、かなり有用なドキュメント (依存関係を示すツリー図など) に変換できます。BLL から同じ種類の情報を抽出することは、かなり深刻なプロジェクトになる可能性が高くなります。

確かに、いくつかの反対方向のポイントがあり、これらすべてを手動で作成する理由があります。スケーラビリティとパフォーマンスが最も明白です。ただし、そのルートに行くとき/場合は、そのパフォーマンスを得るために何をあきらめているかに注意する必要があります. 場合によっては、トレードオフの価値がありますが、そうでない場合もあり、合理的な決定を下すには情報が必要です。

score 8 · Accepted Answer

関係は、ビジネスロジック層で維持される場合があります。BLL にバグがなく、常にバグがないことを 100% 保証できない限り、データの整合性は得られません。そして、あなたはその保証をすることはできません。

また、別のアプリがデータベースにアクセスする場合は、BLL のルールに従う必要はありません (再実装、おそらく微妙に間違った方法で)。 地球上でバグのないコードを書く 3 人のプログラマーの 1 人になったとしても、データが破損する可能性があります。

一方、データベースはすべての人に同じルールを適用します。データベースが適用するルールは、DB が許可しないため、更新時に見落とされる可能性がはるかに低くなります。

score 5 · Accepted Answer

質問が基づいているパフォーマンスの仮定は、原則として正しくありません。通常、RI を適用する必要がある場合は、アプリケーションではなくデータベースが最も効率的な場所です。それ以外の場合、アプリケーションは、データベースの外部で RI を検証できるようにするために、より多くのデータを再クエリする必要があります。

また、データベース内の RI 制約は、クエリオプティマイザーが他のクエリをより効率的にするのに役立ちます。アプリケーションの整合性制約はそれを達成できません。

最後に、すべてのアプリケーションで整合性制約を維持するコストは、一般に、1 か所で一度行うよりも高価で複雑です。

score 5 · Accepted Answer

eBay のテクニカルフェローである Dan Pritchettの話を聞いて、トランザクションや参照整合性などの特定のデータベース構造が、教科書で示されているように義務化されていない理由について説明してください...データの種類、クエリの量、ビジネス要件。それらのバランスをとると、独断的な答えではなく、実用的な解決策につながります...

ただし、BLL でリレーションシップを保持することでデータが保護されるとは限りません。将来の開発者が、"パフォーマンス" の理由で BLL をバイパスする新しい API を公開しない、または単にアーキテクチャを理解していないという保証はできません...

score 3 · Accepted Answer

しかし、イングス大佐、セッションで ID を持つ顧客がいる場合は、すでにデータベースを調べています! 問題は、販売注文を書き留めたが、製品を調べなかったために製品に添付しなかった場合です。どういうわけか、私が現在働いている非常に大きな会社のように、孤立したレコードになってしまうでしょう。歴史のない顧客と顧客のいない歴史があります。何も購入したことのない未払いの顧客と、存在しない顧客に商品を販売する - 興味深いビジネスコンセプト - そして、フルタイムの雇用で非常に欲求不満のサポートスタッフのチームがそれを整理しようとしています. すべてに RI を搭載し、より大きなボックスを購入して、認識されたパフォーマンスの問題を解決した方が、はるかに安価になります。

score 3 · Accepted Answer

DBが制約を検証/制御する最終的な場所であるべきであるという事実については、すでに多くのことが言われています（そして、私はこれ以上同意できませんでした）

データが重要な場合、アプリケーションはデータベースにアクセスする最後のものではなく、唯一のものでもありません。

しかし、参照整合性 (およびその他の制約) に関するもう 1 つの非常に重要な事実があります。それは、データモデルを文書化し、テーブル間の依存関係を明示的にすることです。

パフォーマンスに関する限り、DBMS は制約に依存して適切な最適化を行うことができるため、データベースで FK (またはその他の制約) を定義すると、場合によっては処理がさらに速くなります。

score 2 · Accepted Answer

それはデータに依存します。ビジネストランザクションなどのトランザクション性の高いデータや、頻繁に更新が行われる場所ではない場合、データベースにビジネスルールを適用することは非常に重要です。しかし、他のすべての場合、パフォーマンスへの影響は価値がない可能性があります。

score 2 · Accepted Answer

paxdiablo と dportas が言ったこと。そして私の2セント。他に 2 つの考慮事項があります。

新しい挿入の参照整合性を検証するには、データベースをプローブして、参照が有効であることを確認する必要があります。アプリケーションの整合性を強化する必要性をもたらしたパフォーマンスの向上を無効にしただけです。実際には、DBMS に参照整合性を適用させる方が高速です。

さらに、1 つのデータベースですべてのデータの読み取りと書き込みを行う複数のアプリケーションがある場合を考えてみましょう。ビジネスアプリケーション層で参照整合性を強制する場合は、すべてのアプリケーションが正しく機能することを確認する必要があります。そうしないと、一部の異常なアプリケーションが無効な参照を格納し、別のアプリケーションがデータを使用しようとしたときに問題が表面化する可能性があります。それは本当に混乱です。DBMS ですべてのアプリケーションにデータルールを適用することをお勧めします。

score 1 · Accepted Answer

データベースにレコードを挿入しようとして、参照整合性に失敗するとどうなりますか? データベースからエラーが発生します。次に、無効なデータを挿入しないようにコードを変更する必要があります。参照整合性エラーを回避するには、コードでどのデータがどれであるかを認識している必要があります。したがって、参照整合性は役に立ちません。

Walter Mitty 氏は、「新しい挿入の参照整合性を検証するには、データベースを調べて、参照が有効であることを確認する必要があります」と述べています。はあ…これは完全にナンセンスです。セッションに Customer オブジェクト (メモリ、別名 RAM) がある場合、Customer の ID を知っているので、それを使用して SalesOrder オブジェクトを挿入できます。顧客を検索する必要はありません。

私は現在、厳密な参照整合性を備えたシステムを使用しており、Hibernate は全体的なテンティクルでシステムを包み込んでいます。今まで見た中で最も遅いシステムです。私はそれを設計しませんでした。設計していれば、何倍も速く、保守が簡単になります。休止状態は最悪です。

score 1 · Accepted Answer

ビジネス層で関係を維持している場合は、数年後にはデータベースに不良データが含まれることを保証できます。ビジネス層は、それを行うには最悪の場所です。

さらに、ビジネス層を別のものに置き換える場合、これらすべてを再定義する必要があります。データベースは、元のアプリケーションよりも何年も長持ちすることが多く、データベースが属するデータベースに正しい関係と制約を設定します。

database - 参照整合性を強制する必要がありますか?

11 に答える 11

Related

Reference