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

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

CONSTRAINTデータベース内のsは、そのデータベースにアクセスするアプリケーションによって強制されるべきであることを明らかに示唆していますか？

これが悪い（悪い、悪い...）アイデアである理由はたくさんあります。

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

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

私は以前Oracleフォーラムに頻繁に参加していましたが、一部の貧しいマネージャー/プログラマーが彼の前に仕事をしていた天才があなたが提案することを「明るい」考えにしたプロジェクトを彼に押し付けた回数を話すことはできません。

ジョナサンルイス（彼はOracleオプティマイザーの基礎に関する550ページの本を書いた）は、いいえと答えています。別の本（「テイルズオブジオークテーブル」-オークテーブルはOracleの専門家グループ）にある彼の設計災害の2

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

3）何らかの奇跡によってRIを適切に実装できたとしても、そのデータベースにアクセスするアプリケーションごとに何度も完全に再実装する必要があります。データが重要な場合は、新しいアプリケーションが必要になります。これをパラダイムとして選択すると、あなたとあなたの仲間のプログラマー（サポートスタッフとセールスは言うまでもありません）が絶え間ない消火と悲惨な生活を送ることになります。

あなたは、複数のアプリケーションレベルでのデータの制約を実装する理由について読み狂気の何も短くなることができ、ここで、こことここ。

具体的に質問に答えるには：

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

理由KEYS（いずれかPRIMARY、FOREIGN、UNIQUEまたは普通のINDEXことがある一方、ES）が宣言されているが、それである厳密ではない、それは機能のためにそれらを持っているデータベースのために必要な、それは絶対に彼らは機能にそれを宣言するために必要十分。

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

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

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

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

キーを強制するかどうか（おそらくそうすべきです）文書はそれ自体で価値があります。

いくつかの内部アプリケーションコードの代わりにCONSTRAINTを使用する別の理由：

開発者/ dbaがinsert / update / deleteステートメントを使用してDB内のデータを直接変更するとどうなりますか？この場合、アプリケーションに基づいた参照整合性はすべて役に立たなくなります。私は知っています、彼らが何をするか知っているので、RIに煩わされることなく直接データを変更する可能性を好む開発者もいます-少なくともほとんどの時間（しかし常にではありません）

PS：もちろんトリガーを作成することもできますが、通常は非常に遅くなります（制約に比べて）。