คำถามติดแท็ก 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 ข้อ จำกัด หลายคอลัมน์ที่ไม่ซ้ำกันและค่าเป็นศูนย์
ฉันมีตารางดังนี้: 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)ชัดเจนในทุกสถานการณ์ ดังนั้นส่วนแทรกสองรายการต่อไปนี้ต้องส่งผลให้เกิดข้อผิดพลาด: INSERT INTO my_table VALUES (1, 1, 2, NULL); INSERT INTO my_table VALUES (2, 1, …

5
เหตุใดข้อ จำกัด UNIQUE จึงอนุญาตให้ NULL เพียงหนึ่งอันเท่านั้น
ในทางเทคนิค NULL = NULL เป็นเท็จโดยตรรกะนั้น NULL จะเท่ากับ NULL ใด ๆ และ NULL ทั้งหมดนั้นแตกต่างกัน นี่ไม่ควรบอกเป็นนัยเลยว่า NULL ทั้งหมดนั้นไม่เหมือนใครและดัชนีที่ไม่ซ้ำกันควรอนุญาตให้มี NULL จำนวนเท่าใด?

4
อะไรคือความแตกต่างระหว่างคีย์หลักและซุปเปอร์คีย์ใน DBMS
ฉันใหม่สำหรับ DBMS และฉันยังคงเรียนรู้ทฤษฎี ฉันสับสนกับธุรกิจหลักนี้และหลังจาก googling ฉันได้ จำกัด ให้เหลือเพียง 2 ปุ่มเท่านั้นฉันไม่ได้รับ (หลักและกุญแจหลัก) ฉันมีคำถามสองสามข้อเกี่ยวกับ DBMS ฉันจะขอบคุณถ้าคุณสามารถตอบพวกเขาสำหรับฉัน 1) อะไรคือความแตกต่างระหว่างคีย์หลักและซุปเปอร์คีย์ใน DBMS? ขอขอบคุณอย่างสูงหากคุณสามารถใช้ตัวอย่างที่ครอบคลุมเพื่ออธิบายอย่างถูกต้อง 2) คีย์หลักและ Super key ทั้งสองสามารถรวมกันหลายคอลัมน์เพื่อสร้างคีย์หลักและซุปเปอร์คีย์ได้หรือไม่ 3) คีย์หลักเป็นชุดย่อยของ Super key หรือในทางกลับกัน

2
ข้อ จำกัด ของคอลัมน์ที่ไม่ซ้ำกันที่กำหนดเองมีผลบังคับใช้เฉพาะถ้าหนึ่งคอลัมน์มีค่าเฉพาะ
เป็นไปได้หรือไม่ที่จะมีข้อ จำกัด คอลัมน์เฉพาะที่กำหนดเองดังต่อไปนี้ สมมติว่าฉันมีสองคอลัมน์subsetและtypeทั้งสองสตริง (แม้ว่าชนิดข้อมูลอาจไม่สำคัญ) ถ้าtypeเป็น "จริง" ฉันก็อยากจะผสมผสานtypeและsubsetเป็นเอกลักษณ์ มิฉะนั้นจะไม่มีข้อ จำกัด ฉันใช้ 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
ดัชนีค่าใช้จ่ายที่ไม่ซ้ำกัน
ฉันได้มีการถกเถียงอย่างต่อเนื่องกับนักพัฒนาหลายคนในสำนักงานของฉันเกี่ยวกับค่าใช้จ่ายของดัชนีและความเป็นเอกลักษณ์หรือไม่นั้นมีประโยชน์หรือมีค่าใช้จ่ายสูง (อาจเป็นได้ทั้งสองอย่าง) ปมของปัญหาคือทรัพยากรการแข่งขันของเรา พื้นหลัง ก่อนหน้านี้ฉันได้อ่านการสนทนาที่ระบุว่าUniqueดัชนีนั้นไม่มีค่าใช้จ่ายเพิ่มเติมในการบำรุงรักษาเนื่องจากการInsertดำเนินการโดยปริยายจะตรวจสอบว่าตรงกับต้นไม้ B หรือไม่และหากพบซ้ำในดัชนีที่ไม่ซ้ำใคร จุดสิ้นสุดของคีย์ แต่อย่างอื่นแทรกโดยตรง ในลำดับเหตุการณ์นี้Uniqueดัชนีไม่มีค่าใช้จ่ายเพิ่มเติม ผู้ร่วมงานของฉันต่อสู้กับแถลงการณ์นี้โดยกล่าวว่าการUniqueบังคับใช้เป็นการดำเนินการครั้งที่สองหลังจากการค้นหาตำแหน่งใหม่ในต้นไม้ B และทำให้ค่าใช้จ่ายในการบำรุงรักษาสูงกว่าดัชนีที่ไม่ซ้ำใคร ที่แย่ที่สุดฉันได้เห็นตารางที่มีคอลัมน์ข้อมูลประจำตัว (ไม่ซ้ำกันโดยเนื้อแท้) นั่นคือคีย์การทำคลัสเตอร์ของตาราง แต่ระบุไว้อย่างชัดเจนว่าไม่ซ้ำกัน ในอีกด้านหนึ่งของความเลวร้ายที่สุดคือการครอบงำจิตใจของฉันด้วยเอกลักษณ์และดัชนีทั้งหมดจะถูกสร้างขึ้นเป็นเอกลักษณ์และเมื่อไม่สามารถกำหนดความสัมพันธ์ที่ไม่ซ้ำกันอย่างชัดเจนกับดัชนีฉันผนวก PK ของตารางไปยังจุดสิ้นสุดของดัชนีเพื่อรับรอง รับประกันความเป็นเอกลักษณ์ ฉันมีส่วนร่วมในการตรวจสอบโค้ดสำหรับทีม dev บ่อยครั้งและฉันต้องสามารถให้แนวทางทั่วไปเพื่อให้พวกเขาทำตาม ใช่ทุกดัชนีควรได้รับการประเมิน แต่เมื่อคุณมีเซิร์ฟเวอร์ห้าตัวที่มีตารางนับพันแต่ละตัวและมากถึงยี่สิบดัชนีในตารางคุณจะต้องสามารถใช้กฎง่าย ๆ เพื่อรับประกันคุณภาพในระดับหนึ่ง คำถาม เอกลักษณ์มีค่าใช้จ่ายเพิ่มเติมที่ส่วนท้ายของการInsertเปรียบเทียบกับค่าใช้จ่ายในการบำรุงรักษาดัชนีที่ไม่ซ้ำหรือไม่? ประการที่สองมีอะไรผิดปกติในการผนวกคีย์หลักของตารางต่อท้ายดัชนีเพื่อให้แน่ใจว่ามีเอกลักษณ์? ตัวอย่างคำจำกัดความของตาราง create table #test_index ( id int not null identity(1, 1), dt datetime not null default(current_timestamp), val varchar(100) not …

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
เมื่อมองไปที่เอกสารประกอบของ 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 schema Visual Studio เปรียบเทียบเครื่องมือแนะนำการทำเช่นนี้โดย: 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); มันจำเป็นจริงๆหรือ? หรือมากกว่านั้นเป็นวิธีที่ประหยัดมากในการทำเช่นนี้? เมื่อสร้างดัชนีที่ไม่ซ้ำอีกครั้งตารางของฉันจะถูกล็อคหรือไม่ เพราะนี่จะเป็นปัญหาใหญ่ (เนื่องจากตารางมี 30 …

2
ปัญหา PostgreSQL UPSERT ด้วยค่า NULL
ฉันมีปัญหากับการใช้คุณสมบัติใหม่ของ UPSERT ใน Postgres 9.5 ฉันมีตารางที่ใช้สำหรับรวบรวมข้อมูลจากตารางอื่น คีย์ผสมประกอบด้วย 20 คอลัมน์โดย 10 ซึ่งสามารถเป็นโมฆะได้ ด้านล่างฉันได้สร้างรุ่นที่เล็กกว่าของปัญหาที่ฉันมีโดยเฉพาะกับค่าเป็นศูนย์ 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 …

1
N'Șc 'พิจารณาคีย์ที่ซ้ำกันของ N'C' โดยใช้การเปรียบเทียบ Latin1_General_CI_AS
ฉันมีตารางที่มีคีย์เฉพาะที่มีNVARCHAR(50)คอลัมน์ (ถูกต้องหรือไม่ แต่มีอยู่) ดังนั้นเมื่อพยายามที่จะแทรกȘcหรือC(ไม่สำคัญกับคำสั่งของเม็ดมีด) มันจะแตกบนเม็ดที่สองเนื่องจากปัญหาการเรียง นี่คือข้อผิดพลาด: (รับผลกระทบ 1 แถว) ข่าวสารเกี่ยวกับ 2601, ระดับ 14, สถานะ 1, บรรทัดที่ 16 ไม่สามารถแทรกแถวคีย์ซ้ำในวัตถุ 'dbo.testT' ด้วยดัชนีเฉพาะ 'IX_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, …

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 <> …

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.