ทำไมคีย์ต่างประเทศแบบคอมโพสิตจึงจำเป็นต้องมีข้อ จำกัด ที่ไม่เหมือนกัน?


10

นี่คือตารางอย่างง่าย ๆ ที่เรคคอร์ดอาจอ้างอิงเรคคอร์ดหลักในตารางเดียวกัน:

CREATE TABLE foo (
    id         SERIAL  PRIMARY KEY,
    parent_id  INT     NULL,
    num        INT     NOT NULL,
    txt        TEXT    NULL,
    FOREIGN KEY (parent_id) REFERENCES foo(id)
);

ด้วยข้อกำหนดเพิ่มเติมที่หนึ่งในค่าเขตข้อมูลอื่น ( num) จะต้องเหมือนกันระหว่างบันทึกผู้ปกครองและเด็กฉันคิดว่าคีย์ต่างประเทศประกอบควรทำเคล็ดลับ ฉันเปลี่ยนบรรทัดสุดท้ายเป็น

    FOREIGN KEY (parent_id, num) REFERENCES foo(id, num)

และมีข้อผิดพลาด: ไม่มีข้อ จำกัด ที่ไม่ซ้ำกันการจับคู่ปุ่มรับสำหรับตารางการอ้างอิง "foo"

ฉันสามารถเพิ่มข้อ จำกัด นี้ได้อย่างง่ายดาย แต่ฉันไม่เข้าใจว่าทำไมจึงมีความจำเป็นเมื่อหนึ่งในคอลัมน์ที่อ้างอิง ( id) ได้รับการรับรองแล้วว่าไม่เหมือนใคร วิธีที่ฉันเห็นมันข้อ จำกัด ใหม่จะซ้ำซ้อน

คำตอบ:


11

มันเป็นข้อ จำกัด ของ DBMS - ในพวกเขาทั้งหมดเท่าที่ฉันรู้ และไม่เพียง แต่เมื่อเพิ่มคอลัมน์ แต่ยังเมื่อจัดเรียงคอลัมน์ ถ้าเรามีUNIQUEข้อ จำกัด ในการ(a1, a2)ที่เราไม่สามารถเพิ่มFOREIGN KEYว่าREFERENCES (a2, a1)เว้นแต่จะมีข้อ จำกัด ที่ไม่ซ้ำกันในที่(a2, a1)ที่เป็นหลักเป็นซ้ำซ้อน

มันจะไม่ยากอย่างมากที่จะเพิ่มเป็นคุณลักษณะ:

เมื่อมีUNIQUEข้อ จำกัด ใน(a)แล้วใด ๆ(a, b, c, ..., z)หรือการรวมกันนอกจากนี้ยังมีการประกัน(b,c, ...a, ...z)UNIQUE

หรือลักษณะทั่วไป:

เมื่อมีUNIQUEข้อ จำกัด ใน(a1, a2, ..., aN)แล้วใด ๆ(a1, a2, ..., aN, b1, b2, ..., bM)รวมกันหรือปรับปรุงใหม่ใด ๆ UNIQUEนอกจากนี้ยังมีการประกัน

ดูเหมือนว่ายังไม่ได้รับการถามหรือไม่ได้รับการพิจารณาว่ามีความสำคัญสูงพอที่จะดำเนินการ

คุณสามารถขอได้เสมอ - ในช่องทางที่เกี่ยวข้อง - เพื่อใช้งานคุณลักษณะนี้ หรือแม้กระทั่งปรับใช้ด้วยตนเองถ้า DBMS เป็นโอเพ่นซอร์สเช่น Postgres


ฉันไม่แน่ใจว่ามันจะง่ายขนาดนี้ .. แล้วดัชนีบางส่วนหรือค่า NULL ล่ะ? ฯลฯ .. NULL != NULLโมฆะอาจจะยังคงทำงานได้ดีหากคุณกำลังมีความสุขกับ อย่างไรก็ตาม .. :)
Joishi Bodio

@JoishiBodio ฉันไม่คิดว่า Nulls เป็นปัญหา ข้อ จำกัด UNIQUE สามารถกำหนดหรือคอลัมน์ที่ไม่มีค่าเช่นกัน เริ่มต้นคือถ้าคอลัมน์ใดมี NULL แล้วข้อ จำกัด จะถูกส่งและยอมรับแถว
ypercubeᵀᴹ

ในวินาทีที่แม้ว่าถ้า a1, a2, ... aN ไม่เป็นโมฆะและ b1, b2, bM คือเราอาจมีปัญหา แต่คุณสมบัตินี้สามารถนำไปใช้กับคอลัมน์ที่ไม่เป็นโมฆะได้ สิ่งที่น่าเป็นไปได้ก็คือเรื่องประสิทธิภาพ
ypercubeᵀᴹ

ฉันคุ้นเคยกับการUNIQUE INDEXที่คอลัมน์อยู่NULLABLE.. ซึ่งเป็นเหตุผลที่ฉันพูดถึงมัน :) แต่ฉันเห็นด้วย - ในกรณีที่ไม่มีค่า NULL (และไม่ใช่ดัชนีบางส่วน) ก็อาจจะตรงไปตรงมา
Joishi Bodio

5

Foreign Keys โดยทั่วไป (ไม่ใช่แค่คอมโพสิต) ต้องชี้ไปที่ UNIQUE KEY ของบางอย่างในตารางอื่น หากพวกเขาทำไม่ได้ก็จะไม่มีความสมบูรณ์ของข้อมูลเชิงสัมพันธ์

สิ่งนี้กำลังบ่นเพราะในขณะที่คุณมีคีย์เฉพาะบน (id) .. คุณไม่ได้มีคีย์เฉพาะบน (id, NUM) .. ดังนั้นเท่าที่ฐานข้อมูลเกี่ยวข้องคู่ (id, NUM) คือ ไม่รับประกันว่าจะไม่ซ้ำกัน เราในฐานะมนุษย์สามารถคิดได้ว่ามันจะไม่ซ้ำกัน แต่ฉันแน่ใจว่าจะมีรหัสเพิ่มเติมอีกมากมายที่พวกเขาจะต้องเพิ่มเพื่อให้ Postgres ฉลาดพอที่จะเห็นว่า "โอ้เฮ้ .. id ควรจะไม่ซ้ำกัน ดังนั้น id, NUM ควรจะไม่ซ้ำกัน "..

ฉันจะแปลกใจอย่างมากหากพวกเขาเพิ่มรหัสนั้นเมื่อสิ่งที่คุณต้องทำคือการสร้างดัชนีที่ไม่ซ้ำกันอีกสองคอลัมน์เพื่อแก้ไขปัญหา

เพื่อให้ชัดเจนรหัสที่พวกเขาจะต้องเพิ่มจะไม่เป็นเพียงกรณีนี้ ... มันจะต้องจัดการทุกกรณีแม้แต่คนที่มีรหัสต่างประเทศอยู่ในคอลัมน์ 4+ ฯลฯ ฉันแน่ใจ ตรรกะนั้นค่อนข้างซับซ้อน

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