リレーショナルデータベースの制約-完全に削除しないのはなぜですか？

最近（SQLserver内の）テーブル間に制約を作成する理由はありますか？もしそうなら、いつ？私の分野のほとんどのアプリケーションはオブジェクトの原則に基づいて構築されており、テーブルは必要に応じて結合されます。需要は、アプリケーションのニーズに基づいています。単純なルックアップのために束縛されたテーブルをロードすることはありません。順番に（アクションの後）別の単純なルックアップが必要です。

EntityContext、Linq2Data、NHibernateなどのORMツールも、それ自体で制約を処理します。少なくとも、相互に必要なテーブルはわかっています。サーバー内で制約を行うことは、同じ変更を2回行う（強制する）だけのことですか？

これは通常、決定に疑問を投げかけるものではありませんが、このデータベースはまったく異なる設計になっています。設計は通常のように見えますが、ほとんどはアプリケーションで使用されるオブジェクトをミラーリングしています。私を悩ませているのは、SQLserver内で「カスケードなし」に設定されたすべての制約です。つまり、新しいデータベースクエリをコーディングするときは、「検索して検索」する必要があります。場合によっては、1回の削除を行うために最大10レベルの正確な順序が必要です。

これは私を驚かせます、そして、私はそれをどう扱うべきかわかりません。

私の単純な世界では、この設定により、制約のほとんどの目的が失われます。設計に関する知識がなくてもデータベースにホストからアクセスした場合はOKです。

このシナリオでどのように行動しますか？
dbからすべての制約を削除して、アプリケーションレベルで保持しないのはなぜですか。

DBから制約を削除しない 2つの一般的な理由：

• 現在または将来、ORMを使用する場合と使用しない場合があります。これらのアプリの開発者がすべての制約を忠実に複製したとしても（低レベルの非ORMソリューションを使用すると非常に困難になる可能性があります）、常に余分な作業になります。そうでない場合でも、スキーマの整合性を壊すには1つの小さな省略で十分です...これはリスクを避けたいものです。ほとんどの企業では、DBに保存されているデータはビジネスの生命線であるため、あらゆる手段でその整合性を確保する必要があります。そして、これを達成するために試行され実証された最良の手段は、可能な限り多くの制約をDBに実装することです。
• クエリオプティマイザーは、DBレベルで既知の制約に大きく依存しています。制約を削除すると、クエリのパフォーマンスが低下する可能性があります。すぐに気付かないかもしれませんが、いつかあなたにぶつかるでしょう。それまでに手遅れになり、簡単に修正することはできません。性質上、DBのパフォーマンスは、正確なパフォーマンス測定と根本原因を特定するための詳細な分析によって裏付けられた、慎重かつ熟考された設計改善を行う可能性が最も低いピーク負荷時に低下する傾向があります。

あなたの具体的なケースは、DBスキーマがORMツールによって最初に生成された（またはリレーショナルの世界にあまり詳しくない人によって設計された）ように聞こえるので、リレーショナルの観点からは最適ではありません。ORMビューとの一貫性を保ちながら、より「自然な」リレーショナルデザインに向けて分析および改善することをお勧めします。この分析にDBの専門家を関与させると役立つ場合があります。

アプリケーションは行き来できますが、データは永遠に残ります。私の会社では、DBは30〜40歳以上であり、会社が存在する限り存続します。アプリケーションが変わり、開発者が出入りします。整合性と優れた論理データモデルを使用することをお勧めします。そうすれば、複雑なコードベースを経験することなく、誰かがデータを見て有意義な理解を得ることができます。これは、レポートの作成にも役立ちます。また、アプリケーションにはバグが存在する可能性があり、バグが発生する可能性があり、DB制約はそれに対するガードです。私のデフォルトの位置は、可能な限り多くの制約（FKとチェック）を持つことです。
制約を持たない唯一の理由は、設計パターンがそれを許可しない場合（たとえば、階層ごとのテーブルまたはパフォーマンスの問題）です。

私を悩ませているのは、SQLserver内で「カスケードなし」に設定されたすべての制約です。

それは私を邪魔するものではありません。つまり、誰かが良識を示しているということです。カスケード削除は多くの場合、データベースにとって非常に悪いです。そもそも、関連テーブルにデータがある場合に削除を失敗させたい場合があります。たとえば、過去に注文した顧客がいる場合、その顧客を削除したり、注文の対象者に関するデータを失ったり、カスケード削除を行うと、財務報告を混乱させるレコードを削除できます。

開発者の容易さは最も重要なことだと思われるようです。データベースの世界では、これは単に真実ではありません。データの整合性は、パフォーマンスとデータのセキュリティが密接に続く最初の最も重要なことです。クエリの作成に時間がかかる場合は、そうしてください。

データベースは通常、多くのアプリケーション= 1つ以上のWebサイトまたはデスクトップアプリケーション、レポートアプリケーション、Webサービス、クエリウィンドウ、ETLプロセスなどによって処理されます。データベースレベルで制約を実施しない場合、最初に整合性が失われます。それらのアプリケーションの1つとしてのデータのすべてが、すべてのルールに従うとは限りません。第二に、後で別のアプリケーションを使用することにした場合は、これらの制約を複数回コーディングし、書き換える必要があります。第三に、アプリケーションを通じて発生しない何らかのデータ保守タスクを実行する必要があるかどうかを事前に制御することはできません会社が競合他社に買収されたときの別のクライアントへ）。通常、アプリケーション開発者は

私は基本的に言ったどこかを読んだ：データはあなたのアプリケーションの鍵です。あなたのUIでのみEVERアクセスデータがする場合は（と私が意味する、これまで、今と永遠のように、すべての永遠...またはアプリケーションの寿命のために、とにかく）あなたは、データベースの制約を必要としません。ただし、Webサービス、パブリックAPI、rakeタスク/ SQLジョブ/ cron /自動スクリプトなど、アプリ自体以外のものがデータに触れる必要がある可能性があります。そうすれば、潜在的なトラブルを大幅に軽減できます。 DBの制約を維持することにより、

これは、DRYを適用すべきではないソフトウェア開発の1つの領域であると固く信じています（そして、私はその声明に対して多くのダウン票を期待しています）。データはアプリケーションの核心です-修復できないほど破損している場合、それはゲームオーバーです。IMOが必要とするすべての場所で制約を強制することは価値があります。DBレベルでのトリガーと制約、ミドルウェアでのサーバー側の検証、およびUI（Webアプリの場合）でのクライアント側のJavascriptの形式である場合、データが常に初期状態であることを保証するのはIMOにとって必要な悪です。

ORMの意味を知っていますか？オブジェクトリレーショナルマッピング。Wikipedia「互換性のない型システム間でデータを変換するためのテクニック」を引用。うん、リレーショナルとオブジェクトモデルは一緒に適合しません。ORMは、両方の型システムのルールを尊重することで、かなり良い変換を行います。RDBMSは、制約を使用してデータの整合性を実現するように編成されています。一般的に、整合性は非常に優れているため、ORMはオブジェクトデータを格納するためのデータモデルを作成するときにそれらを使用する傾向があります。ORMには、「非カスケード」制約を使用する正当な理由がある可能性があります。また、特定のオブジェクトを作成/更新/ドロップするだけでなく、複雑なクエリを作成する必要がある場合、ORMの設定に問題があります。

リレーショナルコンセプトが迷惑だと思うのなら、なぜオブジェクトデータベースを使用しないのですか？少し前までは速度が遅かったので（ほとんどの人がまだRDBMSを使用しているのですが）、私が聞いたことから物事は少し変わりました。あなたはすべてのリレーショナルニッピックを取り除くでしょう。単にオブジェクトを入力し、オブジェクトを出力します。

それがeBayが行ったことであり、おそらく世界最大のデータベースの1つを持っています。

http://www.dba-oracle.com/oracle_news/news_ebay_massive_oracle.htm http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

参照整合性によってパフォーマンスが向上するということについて上で述べてきたことにもかかわらず、実際には低下する可能性があります。これが、大規模なデータベースが制約を取り除き、アプリケーション層で作業を行っている理由です。そして私が知る限り、それが唯一の本当に正当な理由です。

これらの制約を削除すると、データをクリーンに保ち、それ自体の問題を引き起こすセーフティネットを本質的に失うことになります。すべてと同様に、それはバランスのとれた行為です。一般に、参照整合性を維持することは正しいことだと思います。

強い参照整合性を備えた開発環境で作業したことがあるので、開発者の観点から見ると、それが完全な苦痛になる可能性があることを知っています。多くの場合、開発環境では少しのダーティデータは重要ではなく、行を削除する方法を決めるのに1時間以上かかる場合があります。ただし、制約によりスキーマが明示されるため、非常に便利です。

最初に-私の答え：いいえ、データの世話をするのにアプリケーションだけに頼るべきではありません。

これは、より大きな議論を指し示しています。ORMは、多くの場合、正規化/参照整合性を犠牲にして、「直接的な」DB相互作用に対する軽daの文化を奨励しています。テーブルは、リレーショナルモデルで暗黙的な設計を犠牲にして、任意のオブジェクト階層に強制的にマップされます。OOPが好むデカップリングは、アプリケーションがデータ構造でデザインを感じさせるため、ここではほぼ間違いなく犠牲になっています。ORMは優れた有用性を実証していますが、SQLの悪用または不信に基づいているようです。

新しいパラダイムは（再）出現しています。たとえば、関数型プログラミングを取り上げます。開発チームが新しいプログラミング方法論を採用することを決定した場合、ORMの要件に従って構造化されたデータにどのような影響がありますか？

@Jacek Pruciaに同意します。ORMはRDBMSによく合わないと思います。個人的にRDBMSでDBALを選択するか、ORMでOODBを選択します。

制約は、データベースレベルで一貫性とデータの整合性を確保する唯一の保証です。もちろん、アプリケーションコードを使用して制約を適用できますが、将来、データを直接変更する必要がある場合はどうでしょうか。データの整合性を維持する方法を理解しているかもしれませんが、他の誰かはそうではないかもしれません。制約をデータレベルで保持することで、誰かが理解できない場所でうろついている場合でも、整合性が保証されます。

さらに、アプリケーションを書き換える必要があるが、同じデータベースを使用する必要があるとしましょう。コード内のこれらの制約はすべて、誤ったデータの通過を許可しながら、一部のエントリを妨げるバグをただ懇願しています。

開発するときは、シンプルにしてください。制約により、それが可能になります。（つまり、制約がエラーをスローした場合、ユーザーに同じエラーを返さないでください。エラーを理解できるようにします。）

（カスケードの問題に関しては、それは良いことです。すべてを正しくするためにカスケードに依存するのではなく、最初に他の特定のレコードを削除する必要があるというエラーをスローすることを好みます。実際にはそうです。）

データベースの制約に関する問題の1つは、プログラムに障害の内容と修正方法に関する情報が限られていることです。これは、スムーズな処理のために、アプリケーションで制約チェックを繰り返す必要があることが多いため、データベースの制約チェックが無駄になることを意味します。

これは、データの整合性を損なう危険性があるため、ここでトレードオフがあります。重要なデータの場合、ほとんどの場合、データの整合性を確保することはパフォーマンスよりも重要であり、データを台無しにするよりもarbitrary意的に見える場合でもトランザクションを失敗させる方がはるかに優れています。

したがって、制約を安全に削除するには、データベースアクセスを保護して、制約をチェックしない限りデータベースを変更できないようにすることが重要です。新しいアプリケーションを作成するとき、またはデータを処理するアドホックな方法を考え出すとき、これは信頼できません。必要なのは1つの間違いであり、データベースが破損しているためです。

したがって、データベースの制約をなくすために、データベースでできることとできないことを前もって確立し、すべてのアプリケーションを広範囲に記述、レビュー、およびテストできるようにする必要があります。すべてのデータベース要件を事前に確立する必要があります。データベース要件を変更するには、広範な作業が必要です。これは凍結された滝の方法論の一種であり、非常に特定の場合にのみ機能します。（要件を設計、実装、および維持することは、水の上を歩くことに似ています。まず何かを凍結する必要があります。凍結しなければ、結果は悲惨なものになります。）

動作する1つのケースは、PeopleSoftやSAPのような大規模なエンタープライズアプリケーションです。このアプリケーションは、ほぼすべてをすでに実行しており、拡張する方法は慎重に定義されています。他にも非常にまれな可能性があります。

したがって、非常に大規模なエンタープライズプロジェクトに取り組んでいない場合（そして、私はそうしたくありません）、または液体の水の上を歩くことができる場合を除き、データベースにこれらの制約を残します。