私が大学で学んでいたとき、彼らは私たちにデータベースの基礎、基本、および規則を教えてくれました。最も重要な規則の 1 つは制約 (主キー、外部キー) であり、1-m、1-1、mn の関係を作成する方法です。 .
今、私が実際のビジネス環境に移ると、彼らはこう言います。制約はありません。これらの関係はすべて論理的であり、主キーも外部キーもありません。コードを使用して制約を作成できます。
学問生活で学んだことと、新しい実際のビジネス生活で学ぶことのどちらが正しいかはわかりません。どう思いますか？
2251 次
10 に答える
29
データベースのキーと制約を無視するよう誰かに言われた場合、私はすぐにそれらを無視して、自分の仕事に取り掛かります。
主キー、外部キー、および制約が存在するのには理由があります。それらを使用します。それらを使用すると、作業が楽になり、データベースが理解しやすくなります (そして、多くの場合、パフォーマンスが向上します)。
于 2010-09-13T13:41:22.340 に答える
12
データベースを扱う時間が長くなればなるほど、制約を理解するようになります。長い目で見れば、彼らは私に多くの時間を節約してくれます。信頼できる制約のみが、データの 100% の有効性を保証します。
制約の使用と、データの整合性を保証するその他の方法についての章を書きました。ここから無料でダウンロードできます。
于 2010-09-13T14:56:20.487 に答える
11
制約が単に主キーと外部キーに関するものであると考える場合、実際には、そもそも「基本」の多くを教えられていません。
オンラインで無料で入手できる Hugh Darwen著の「An Introduction to Relational Database Theory」を参照することをお勧めします。そして少なくとも、そこから「基礎」についての真の教育を受けることができます。
于 2010-09-13T13:48:48.323 に答える
6
制約は、クリーンなデータを得るのに役立つと思います。パフォーマンスが向上する場合があります。場合によっては、制約があることによってパフォーマンスが影響を受ける可能性があります。ただし、その答えは制約を取り除くことではありません。パフォーマンスの問題に対処するのに役立つ「非正規化」と呼ばれるものがあります (クエリが既に最適化されている場合)。このようなシナリオでは、いつでも非正規化されたサマリー テーブルを作成できます。
「習ったことは忘れろ」と言った人は、運転教習で習った交通ルールも忘れたと言っていましたか？
于 2010-09-13T13:49:34.187 に答える
5
データベースの制約は、データを破損する可能性のあるデータベースにアクセスするユーザー (つまり、任意のユーザー) がいる場合に最適です。データベースのデータを編集する人が、他のテーブルが現在のテーブルのデータに依存していることを認識できるように、外部キー制約を適切に維持する傾向があります。
于 2010-09-13T13:41:27.020 に答える
4
あなたが学んだことは、学問的なことだけではありません。しかし、そうです、それは時々プラトンのユートピアのようです. これは、データベースが存在できる完璧な状態であり、理想的な設計です。しかし、その理想的な設計が常に可能であるとは限りません。
制約は、可能な限り DB データに近づける必要があります。このように考えてみてください。制約をコードで記述し、後で別の言語/プラットフォームに移行する必要があり、制約の 1 つでエラーが発生した場合はどうなるでしょうか? それは悲惨だろう。PK、FK、制約などは広く使用されています。それらは30年以上使用されています。したがって、それらはジャンクではありませんが、特定のシナリオでは扱いにくいだけです。たとえば、あなたが Google なら、リレーショナル モデルだけに頼ってミリ秒単位で答えを出すことはできません。
したがって、速度や安定性などの要件に基づいて、データを複製したり、PK を使用したり、関係を確立したりしないこともあります。ただし、特定の何かを探しているときと、失うものを知っているときだけです。そのようにすることで。
結局のところ、リレーショナル モデルは単なるモデルにすぎません。物事を表現する方法です。非常に成功した方法ですが、天の恵みではないため、場合によっては妥協する必要があります。
于 2010-09-13T13:41:43.410 に答える
4
私は多くの時間を費やして、制約がアプリケーション コードにあると考えている無能な人によって生成されたがらくたデータを修正しました。データベースがこれらの必要なものなしで設計されている場合、データは正しくありません。数年間実行されているこのようなシステムを簡単にチェックすると、孤立したレコードや必要な情報の欠落などを見つけることができます.
于 2010-09-13T18:16:27.993 に答える
4
確かに、究極の真実がほとんどないことは確かです。また、商業的に成功している多くの製品が、宣言された参照整合性 (DRI) を避けていることも事実です。
一方、データベース内のデータを気にしている場合、そのデータの整合性を保護するには、DRI よりも優れた方法はほとんどありません。
最上位のコードにすべてを任せると、他の方法で誰もデータベースにアクセスしないという希望に頼っていることになります。その場合、データの破損 (孤立した行、一貫性のない非論理的なデータ) を止めることはできません。
于 2010-09-13T13:41:10.447 に答える
-3
私がクラスにいたとき、生の SQL を使用してテーブルにアクセスしましたが、生の SQL または同等のものがたくさんあります。このような場合、制約は一般的に適切です。
ただし、データベースをバックエンドとして使用するシステムがあり、これらのデータベースはその特定のソフトウェア システムによってのみアクセスされます。この場合、ソフトウェアは必要な関係と制約を追跡する必要があり、データベースは冗長なチェックとして機能し、適切なフィードバックを提供せず、パフォーマンスを低下させます。
接続されたシステムが制約自体を維持する必要があるため、データベースの制約は冗長です。フィードバックは、特定のデータベース制約に違反したというものです。プログラムがそのようなフィードバックを処理できる場合、独自のチェックを行うことができます。パフォーマンスのコストは明らかです。
制約は開発システムやテスト システムでは依然として有用ですが、システムが本番環境に入ったときにできることは、何か問題が発生した場合にシステムをクラッシュさせることだけです。これは、通常、次のような大規模システムで発生したくないことです。それ。
于 2010-09-13T18:10:45.840 に答える
-4
主キーは重要です。行を一意に識別する方法が必要です。
しかし、私の経験では、データベースへのアクセスをクラス内に適切にカプセル化すれば (つまり、データベースとの間でオブジェクトの読み取り/書き込みを行う場合)、制約は一般的に必要ありません。ええ、10 の異なる言語の 50 の異なるアプリが同じデータベースを使用している場合、それらを使用する可能性があります。しかし、それが 1 つのアプリ、またはソース コード ベースを共有する共通のアプリ スイートである場合、アプリをより保守しやすくするために、すべてのデータベース操作ロジックを 1 か所に配置したいと考えています。ストアド プロシージャについても同じことが言えますが、さまざまなデータベースを処理するためのコードを記述する場合、db システム間の移植性という追加の問題があります。
于 2010-09-13T17:59:13.137 に答える