web-dev-qa-db-ja.com

キーを明示的にする必要があるのはなぜですか？

私はデータベースの主題に非常に慣れていないので、これは無知に聞こえるかもしれませんが、テーブル内でキーを明示的にする必要がある理由に興味があります。これは主に、指定された列の値が（できれば）各行内で一意であることが保証されていることをユーザーに伝えるためのものですか？一意性は、言及されていなくても存在する必要があります。

primary-keyunique-constraint
15
dsaxton

あなたは明らかに、データベース内のCONSTRAINTsが、そのデータベースにアクセスするアプリケーションによって強制される必要があることを示唆していますか？

これが悪い（悪い、悪い...）アイデアである理由はmanyです。

1）「独自のロール」制約「エンジン」を構築する場合（つまり、アプリケーションコード内）、Oracle/SQL Server/MySQL/PostgreSQL/<。whoever ...>が費やしたものをエミュレートするだけです。 年書き込み。それらのCONSTRAINTコードは、文字通り何百万エンドユーザーによってそれらの年の間テストされました。

2）あなたとあなたのチームにすべての敬意を払って、あなたは数年でそれを正しくするつもりはありません- here から、MySQLコードだけで4,000万ドルかかります。また、MySQLは上記の3つのサーバーの中で最も安価であり、CHECK CONSTRAINTも実装していません。明らかに、R.I。（参照整合性）を完全に正しくすることは困難です。

私はOracleフォーラムに頻繁にアクセスしていましたが、貧しいマネージャー/プログラマーがプロジェクトに彼を突き刺したことが何回あったか、その前に彼の仕事をした天才があなたが提案することを「明るい」考えていたことがわかりません。 。

Jonathan Lewis（彼は Oracle optimiser の基礎について550ページの本を書きました）はノーと言っています。別の本の彼の設計災害の2つ（ " Tales of the Oak Table "-The Oak Table is a group of Oracle Experts）は、

  1. Oracleの制約チェック機能を利用する代わりに、アプリケーションレベルでデータの整合性をチェックします。

3）miracle RIを適切に実装できたとしても、completelyそのデータベースにアクセスするすべてのアプリケーションに対して何度も再実装する必要があります-データが重要なのは、新しいアプリケーションです。これをパラダイムとして選択すると、あなたとあなたの仲間のプログラマー（サポートスタッフとセールスは言うまでもありません）は、常に消火活動と悲惨さを経験することになります。

アプリケーションレベルでのデータ制約の実装が狂気 here 、 here および here にほかならない理由についての詳細を読むことができます。

質問に具体的に回答するには：

なぜ彼らはまったく宣言されているのですか？非常に役立つようですが、実際に機能するデータベースが必要ですか

KEYs（PRIMARY、FOREIGN、UNIQUEまたは通常のINDEXes）が宣言されている理由は、それが- 厳密にではないデータベースがそれらを機能させるために必要、それは絶対に機能させるためにそれらを宣言するために必要well。

32
Vérace

データベースにキーを作成すると、DBMSエンジンはキー属性に一意性制約を適用します。これは、少なくとも3つの関連する目的を果たします。

  • データの整合性：重複するデータをキー属性に入力することはできません。したがって、キーへの依存は保証されます。
  • 識別：ユーザーは、データを正確に識別および更新する手段としてキーに依存できます。
  • 最適化：どの属性が一意であるかに関する情報（メタデータ）は、DBMSクエリオプティマイザーで利用できます。この情報により、オプティマイザは特定の方法でクエリの実行を簡略化し、クエリの実行を高速化できます。
10
nvogel

既存の優れた回答に1つの側面を追加します。Documentation。エンティティを識別するために使用できるキーの種類を確認することがしばしば重要です。一意の列の任意の組み合わせが候補キーです。

主キーは、実際には特に有用な概念になる傾向があります。

キーを強制するかどうかにかかわらず（おそらくそうする必要があります）、ドキュメント自体は貴重です。

8
boot4life

アプリケーションコードの代わりにCONSTRAINTを使用する必要があるもう1つの理由：

開発者/ dbaが挿入/更新/削除ステートメントを使用して、DB内のデータを直接変更するとどうなりますか？この場合、Niceアプリケーションベースの参照整合性はすべて役に立たなくなります。私は知っています。一部の開発者は、RIに煩わされることなくデータを直接変更できる可能性を好みます。少なくともほとんどの場合（常にではありません）

PS：もちろん、トリガーを作成することもできますが、通常はひどく遅い（制約と比較して）。

5
Thomas Franz