2017-12-15 136 views
0

2つのフィールドに基づいたユニーク制約の論理を理解できません。重複のないUPDATE文のORA-00001

私は3つの列を含むDESCRIPTIONSという名前の次のテーブルがあります。今ID_DESCRIPTIONNAMEID_DESCRIPTION_TYPE

ID_DESCRIPTIONprimary keyあり、カップル(ID_DESCRIPTIONNAME)のunique constraintUK_DESCRIPTIONがあります。私は次のクエリを実行しようとした場合

UPDATE DESCRIPTIONS SET NAME = 'USA' WHERE ID_DESCRIPTION = 9255813 

を私はユニーク制約UK_DESCRIPTIONに違反していることを言って、ORA-00001例外を取得しています。

これで、カップル(9255813,)が既に存在することを意味しますか? ID_DESCRIPTIONであるため しかし、私はこれが可能であるかを確認していないprimary keyため、独自のクエリ

SELECT * FROM DESCRIPTIONS WHERE ID_DESCRIPTION = 9255813 

の結果のみが1つの結果、私は更新したいものを返します。 私はここで何が分からないのですか?

Constraint snapshot from toad

+0

質問を編集して、すべての制約とインデックスを含む完全な 'create table'文をテーブルに追加してください。 [**フォーマットされたテキスト**](http://stackoverflow.com/help/formatting)、[スクリーンショットなし](http://meta.stackoverflow.com/questions/285551/why-may-i-not -upload-images-of-code-on-so-asking-a-question/285557#285557) –

答えて

1

私はuk_descriptionが実際にNAMEの単一の列に基づく固有のキーであることを推測するつもりです。

「残念ながらです。」

もう1つの説明は、考えているものとは異なる列のセットに基づいた複数列のキーです。 (NAME, ID_DESCRIPTION_TYPE)も、説明した動作に適合します。

公正であるためには、(NAME, ID_DESCRIPTION_TYPE)のユニークなキーが理にかなっています。たとえば、これはテーブルが単一の参照データのルックアップ(恐ろしいモデルですが十分に一般的です)の場合に必要なキーです。一方、複合キーID_DESCRIPTION, NAME)は、主キーを弱体化するだけです。

+0

残念ながらそうではありません。 – Marc

+1

あなたは実際にそれほど遠くにいませんでした。私は制約を正しく読まず、(ID_DESCRIPTION_TYPE、NAME)に基づいていて、(ID_DESCRIPTION、NAME)ではありません – Marc

+1

それは二番目の推測としてそれをタイプしていました。 – APC

関連する問題