タグ付けされた質問 「unique-constraint」

DDL UNIQUE制約は、列または列のグループに含まれるデータがテーブル内のすべての行の間で一意であることを保証します。したがって、関連する列に含まれるデータは、関連するテーブルの行を一意に識別するのに役立ちます。

6
一意のインデックスの代わりに一意の制約を使用する必要があるのはいつですか?
列に個別の値が必要な場合は、制約を使用できます create table t1( id int primary key, code varchar(10) unique NULL ); go または、一意のインデックスを使用できます create table t2( id int primary key, code varchar(10) NULL ); go create unique index I_t2 on t2(code); 一意の制約を持つ列は、一意のインデックスの適切な候補のようです。 一意の制約を使用し、代わりに一意のインデックスを使用しない既知の理由はありますか?

3
PostgreSQLの複数列の一意制約とNULL値
次のような表があります。 create table my_table ( id int8 not null, id_A int8 not null, id_B int8 not null, id_C int8 null, constraint pk_my_table primary key (id), constraint u_constrainte unique (id_A, id_B, id_C) ); そして、私(id_A, id_B, id_C)はどんな状況でも明確になりたいです。したがって、次の2つの挿入はエラーになる必要があります。 INSERT INTO my_table VALUES (1, 1, 2, NULL); INSERT INTO my_table VALUES (2, 1, 2, ...


4
DBMSの主キーとスーパーキーの違いは何ですか
私はDBMSに不慣れで、まだ理論を学んでいます。 私はこの重要なビジネスに本当に混乱しており、グーグルで検索した後、取得できない2つのキー(プライマリキーとスーパーキー)に絞り込みました。 DBMSに関していくつか質問があります。あなたが私のためにそれらに答えることができれば私は感謝するでしょう。 1)DBMSのプライマリキーとスーパーキーの違いは何ですか? 包括的な例を使用して適切に説明できる場合は、高く評価してください 2)プライマリキーとスーパーキーの両方に複数の列を組み合わせて、プライマリキーとスーパーキーを形成できますか? 3)主キーはスーパーキーのサブセットですか、またはその逆ですか?

2
1つの列に特定の値がある場合にのみ適用されるカスタムの一意の列制約
次のようにカスタムの一意の列制約を持つことは可能ですか?2つのcol subsetとtype、両方の文字列があると仮定します(データ型はおそらく重要ではありませんが)。 Ifはtype「真」である、私はの組み合わせをしたいtypeとsubset一意です。それ以外の場合、制約はありません。DebianでPostgreSQL 8.4を使用しています。


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

2
アトミックトランザクションで一意の違反を回避する
PostgreSQLでアトミックトランザクションを作成することはできますか? これらの行を持つテーブルカテゴリがあると考えてください。 id|name --|--------- 1 |'tablets' 2 |'phones' また、列名には一意の制約があります。 私が試した場合: BEGIN; update "category" set name = 'phones' where id = 1; update "category" set name = 'tablets' where id = 2; COMMIT; 私は得ています: ERROR: duplicate key value violates unique constraint "category_name_key" DETAIL: Key (name)=(tablets) already exists.

4
インデックスの一意性のオーバーヘッド
私はオフィスのさまざまな開発者と、インデックスのコスト、および一意性が有益であるか高価であるか(おそらく両方)について継続的な議論を行ってきました。問題の核心は、競合するリソースです。 バックグラウンド 操作はBツリーのどこに収まるかを暗黙的にチェックし、一意でないインデックスに重複が見つかった場合は、一意化を追加するため、インデックスUniqueを維持するための追加コストはないという説明を以前読んだInsertことがありますキーの終わりですが、それ以外の場合は直接挿入します。この一連のイベントでは、Uniqueインデックスに追加コストはありません。 私の同僚Uniqueは、Bツリー内の新しい位置へのシーク後の2番目の操作として強制されるため、このステートメントに対抗します。したがって、一意でないインデックスよりも維持にコストがかかります。 最悪の場合、テーブルのクラスタリングキーであるID列(本質的に一意)を持つテーブルを見たことがありますが、明示的に非一意であると述べられています。最悪の反対側には、一意性への執着があり、すべてのインデックスは一意として作成されます。インデックスに明示的に一意のリレーションを定義できない場合は、テーブルのPKをインデックスの末尾に追加して、一意性が保証されます。 私は開発チームのコードレビューに頻繁に関与しており、彼らが従うための一般的なガイドラインを提供できる必要があります。はい、すべてのインデックスを評価する必要がありますが、それぞれ数千のテーブルとテーブルに最大20のインデックスを持つ5つのサーバーがある場合、特定のレベルの品質を確保するためにいくつかの簡単なルールを適用できる必要があります。 質問 一意性には、Insert非一意のインデックスを維持するコストと比較して、バックエンドで追加コストがかかりますか?第二に、一意性を確保するためにインデックスの最後にテーブルの主キーを追加することの何が問題になっていますか? テーブル定義の例 create table #test_index ( id int not null identity(1, 1), dt datetime not null default(current_timestamp), val varchar(100) not null, is_deleted bit not null default(0), primary key nonclustered(id desc), unique clustered(dt desc, id desc) ); create index [nonunique_nonclustered_example] on #test_index (is_deleted) include ...

1
一意のインデックスの更新と統計行の変更カウンター
次の表、一意のクラスター化インデックス、および統計情報が与えられます。 CREATE TABLE dbo.Banana ( pk integer NOT NULL, c1 char(1) NOT NULL, c2 char(1) NOT NULL ); CREATE UNIQUE CLUSTERED INDEX pk ON dbo.Banana (pk); CREATE STATISTICS c1 ON dbo.Banana (c1); CREATE STATISTICS c2 ON dbo.Banana (c2); INSERT dbo.Banana (pk, c1, c2) VALUES (1, 'A', 'W'), (2, 'B', 'X'), ...

2
postgresの遅延可能な一意のインデックス
alter tableのpostgresのドキュメントを見ると、通常の制約はDEFERRABLE(より具体的には、INITIALLY DEFERRED、これが私が興味を持っていることです)。 次の条件を満たしている限り、インデックスを制約に関連付けることもできます。 インデックスには式列を含めることも、部分インデックスにすることもできません そのため、現在、次のような条件付きの一意のインデックスを作成する方法はないと考えています。 CREATE UNIQUE INDEX unique_booking ON public.booking USING btree (check_in, check_out) WHERE booking_status = 1; であるためにINITIALLY DEFERRED(場合一意「制約」は唯一のトランザクションの最後に検証されることを、意味し、SET CONSTRAINTS ALL DEFERRED;使用されています)。 私の仮定は正しいですか、もしそうなら、意図した動作を達成する方法はありますか? ありがとう

1
nvarchar列のサイズを変更する場合、一意のインデックスを削除する必要がありますか?また、インデックスの再作成時にテーブルがロックされますか?
私たちのデータベースには、次のような多かれ少なかれ大きなテーブルがあります。 CREATE TABLE dbo.production_data ( pd_id BIGINT PRIMARY KEY, serial NVARCHAR(16) NOT NULL UNIQUE, ... ); しかし、今ではシリアルフィールドのサイズが小さくなっているので、32に変更したいと思います。VisualStudioスキーマ比較ツールは、これを行うことを提案します。 DROP INDEX ux_production_data_serial ON dbo.production_data; GO ALTER TABLE dbo.production_data ALTER COLUMN serial NVARCHAR(32) NOT NULL; GO CREATE INDEX ux_production_data_serial ON dbo.production_data(serial ASC); これは本当に必要ですか?それとも、これを行う超保存的な方法のようなものですか? また、一意のインデックスを再作成すると、テーブルがロックされますか?これは大きな問題になるためです(テーブルには3,000万行あり、インデックスの再作成にはかなり時間がかかると思います)。これは、次のメンテナンスウィンドウが数か月先になるためです。私の選択肢は何ですか?

2
NULL値に関するPostgreSQL UPSERTの問題
Postgres 9.5の新しいUPSERT機能の使用に問題があります 別のテーブルからデータを集計するために使用されるテーブルがあります。複合キーは20列で構成され、そのうち10列はNULL可能です。以下に、特にNULL値を使用して、私が抱えている問題のより小さなバージョンを作成しました。 CREATE TABLE public.test_upsert ( upsert_id serial, name character varying(32) NOT NULL, status integer NOT NULL, test_field text, identifier character varying(255), count integer, CONSTRAINT upsert_id_pkey PRIMARY KEY (upsert_id), CONSTRAINT test_upsert_name_status_test_field_key UNIQUE (name, status, test_field) ); このクエリの実行は、必要に応じて機能します(最初の挿入、その後の挿入は単純にカウントを増やします)。 INSERT INTO test_upsert as tu(name,status,test_field,identifier, count) VALUES ('shaun',1,'test value','ident', 1) ON CONFLICT ...

1
N'Șc 'は、Latin1_General_CI_AS照合を使用してN'C'の重複キーを検討しました
NVARCHAR(50)列を含む一意のキーを持つテーブルがあります(正しいかどうかはわかりますが、あります)。そのため、挿入しようとすると、ȘcまたはC(挿入の順序は関係ありません)、照合の問題により2番目の挿入で中断します。ここにエラーがあります: (1行が影響を受けました)メッセージ2601、レベル14、状態1、行16一意のインデックス 'IX_TestT'を持つオブジェクト 'dbo.testT'に重複するキー行を挿入できません。重複するキーの値は(C)です。 返品を選択: データベースのデフォルトの照合はLatin1_General_CI_ASです。既存の構造をあまり変更せずに、その解決方法をしばらく探しましたが、機能する方法を見つけることができませんでした。さまざまな照合順序と組み合わせを試しましたが、すべて失敗します。まだ展開されていないキャラクターの展開などについて(こことここ)を読んでください。これは、問題を再現するために使用しているサンプルコードです。自由に変更し、これを解決するのに役立つと思われるものをお勧めします。 CREATE TABLE testT ( [Default_Collation] [NVARCHAR] (50) COLLATE DATABASE_DEFAULT, [Latin1_General_CI_AS] [NVARCHAR] (50) COLLATE Latin1_General_CI_AS, [Latin1_General_CI_AI] [NVARCHAR] (50) COLLATE Latin1_General_CI_AI, [SQL_Collation] [NVARCHAR] (50) COLLATE SQL_Latin1_General_CP1_CI_AS); CREATE UNIQUE CLUSTERED INDEX [IX_TestT] ON [dbo].[testT] ([Default_Collation]) ON [PRIMARY] GO INSERT INTO testT SELECT N'Șc', --COLLATE Latin1_General_CI_AS N'Șc', --COLLATE ...

5
この更新が一意キー制約違反で失敗するのはなぜですか?
私は「偶然の」DBAであり、比較的経験が浅く、この問題に困惑しています。 MS SQL Server 2012を実行しています。問題はこのUPDATEステートメントにあります。 UPDATE dbo.tAccts SET Ticket = 'ARP.ExGE' , Method = 'smtp' , AcctOwner = 'r00417819' , DisplayName = '~AppLight HBSFax-Inactive' , Destination = 'r00417819@mail.ad.ge.com' , UpdatedBy = SYSTEM_USER , UpdatedOn = CAST(GetDate() AS DATE) FROM dbo.vReclaimable WHERE OHR_EmpStatus <> 'A' これは、vReclaimableビューによって返されるtAcctsテーブルの行のみを更新する必要があります。 vReclaimableビューはtAcctsテーブルに基づいており、tAcctsの行のサブセットを返します。 実行すると、一意のキーエラーで失敗します。 (0 row(s) affected) ...

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.