คีย์ต่างประเทศจำเป็นในการออกแบบฐานข้อมูลหรือไม่?

109

เท่าที่ฉันทราบมีการใช้คีย์ต่างประเทศ (FK) เพื่อช่วยโปรแกรมเมอร์ในการจัดการข้อมูลด้วยวิธีที่ถูกต้อง สมมติว่าโปรแกรมเมอร์กำลังทำสิ่งนี้ในลักษณะที่ถูกต้องอยู่แล้วเราต้องการแนวคิดของคีย์ต่างประเทศหรือไม่?

มีการใช้คีย์ต่างประเทศอื่น ๆ หรือไม่? ฉันขาดอะไรที่นี่?

database oracle foreign-keys

— นิยาซ
แหล่งที่มา

2

ขึ้นมาแถว ๆ นี้บ่อยๆ ฉันตำหนิJoel Spolsky :-) มีคำตอบที่ดีมากมายที่นี่ แทนที่จะพิมพ์ใหม่ฉันจะให้ลิงค์: stackoverflow.com/questions/83147/whats-wrong-with-foreign-keys

— SquareCog

70

"สมมติว่าโปรแกรมเมอร์ทำสิ่งนี้อย่างถูกต้องอยู่แล้ว" - ฉันนึกภาพไม่ออกเลยว่า

— ออกอากาศซ้ำ

11

"Foreign Key" คือความคิดไม่ใช่เทคโนโลยี มันเป็นกฎเชิงสัมพันธ์ คำถามของคุณเกี่ยวกับว่าคุณควรพยายามบังคับใช้กฎในโค้ดของคุณหรือให้ฐานข้อมูลช่วยคุณ เมื่อเกี่ยวข้องกับการทำงานพร้อมกันควรให้เอ็นจินฐานข้อมูลบังคับใช้กฎเนื่องจากตระหนักถึงทุกสิ่งที่เกิดขึ้นในฐานข้อมูลในขณะที่โค้ดของคุณไม่สามารถรับรู้ได้

— Triynko

5

@lubos & cdeszaq. จริงๆแล้วมันเป็นกฎเชิงสัมพันธ์ ... มันเป็นชุดย่อยของกฎ 10 ของ "บัญญัติ Twleve" ของ Codd ... "ความเป็นอิสระแห่งความสมบูรณ์" ซึ่งโดยพื้นฐานแล้วกล่าวว่าความสมบูรณ์เชิงสัมพันธ์ของ RDBMS จะต้องได้รับการดูแลโดยไม่ขึ้นกับแอปพลิเคชันใด ๆ ที่เข้าถึงมันซึ่ง คือสิ่งที่ฉันอธิบายอย่างเข้าใจง่าย กฎนี้นำมาใช้โดยข้อ จำกัด ของคีย์ต่างประเทศ ใช่แล้วแนวคิดของคีย์ต่างประเทศคือกฎเชิงสัมพันธ์ "a"

— Triynko

1

@lubos: เพื่อความชัดเจนคุณกำลังพูดถึงว่าคุณจะใช้คุณลักษณะเฉพาะหรือไม่ แต่ฉันกำลังพูดถึงว่าการมีอยู่ของคุณลักษณะนั้นจำเป็นต้องมี RDBMS ที่สมบูรณ์และใช้งานได้อย่างสมบูรณ์หรือไม่ ข้อ จำกัด ในการอ้างอิงหากและเมื่อคุณเลือกใช้เป็นสิ่งที่ควรบังคับใช้ภายใน RDBMS (แทนที่จะเป็นแอปพลิเคชัน) ดังนั้นจึงเป็นคุณสมบัติที่ควรมีและในแง่นั้นจึงเป็นข้อกำหนดของโมเดลเชิงสัมพันธ์หาก คุณกำลังจะพัฒนา RDBMS ที่สมบูรณ์

— Triynko

102

คีย์ต่างประเทศช่วยบังคับใช้ความสมบูรณ์ของการอ้างอิงในระดับข้อมูล นอกจากนี้ยังปรับปรุงประสิทธิภาพเนื่องจากโดยปกติจะมีการจัดทำดัชนีโดยค่าเริ่มต้น

— จอห์น Topley
แหล่งที่มา

52

หากคุณต้องการสร้างดัชนีขึ้นมานี่ไม่ควรเป็นเหตุผลหลักสำหรับ FK (ในความเป็นจริงในบางสถานการณ์ (เช่นเม็ดมีดมากกว่าที่เลือก) การรักษา FK อาจช้ากว่า)

— Robert

7

นั่นเป็นคำตอบที่น่าสยดสยอง FKs โดยทั่วไปสามารถเพิ่มค่าใช้จ่ายพิเศษไม่ได้ช่วยเพิ่มประสิทธิภาพ

— Agile Jedi

ใน SQL-Server จะไม่ถูกสร้างดัชนีตามค่าเริ่มต้นทั้งในผู้ตัดสินหรือผู้อ้างอิง sqlskills.com/blogs/kimberly/…

— user420667

1

หรือใน Oracle; คุณต้องสร้างดัชนี (บนคอลัมน์ FK) ด้วยตัวเอง

— Littlefoot

58

ON DELETE CASCADEคีย์ต่างประเทศยังสามารถช่วยให้การเขียนโปรแกรมเมอร์น้อยรหัสโดยใช้สิ่งที่ต้องการ ซึ่งหมายความว่าหากคุณมีตารางหนึ่งที่มีผู้ใช้และอีกตารางหนึ่งมีคำสั่งซื้อหรือบางอย่างการลบผู้ใช้อาจลบคำสั่งซื้อทั้งหมดที่ชี้ไปยังผู้ใช้นั้นโดยอัตโนมัติ

— Greg Hewgill
แหล่งที่มา

3

@Greg Hewgill สิ่งนี้อาจนำไปสู่ปัญหามากมาย คุณควรใช้ความระมัดระวังในการคิดเช่น DELETE CASCADE เนื่องจากในหลาย ๆ กรณีคุณต้องการเก็บคำสั่งซื้อที่สร้างโดยผู้ใช้เมื่อลบผู้ใช้

— Kibbee

8

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

— Codewerks

5

ปัญหาอื่น ๆ คือการตรวจสอบหากไม่ได้ทำการตรวจสอบที่ระดับฐานข้อมูลการอัปเดตหรือการลบแบบเรียงซ้อนจะทำให้เส้นทางการตรวจสอบของคุณเป็นโมฆะ

— si618

@Codewerks: ตรรกะทางธุรกิจสามารถอยู่ในฐานข้อมูลได้

— Fantius

44

ฉันนึกภาพไม่ออกว่าออกแบบฐานข้อมูลโดยไม่มีคีย์ต่างประเทศ หากไม่มีพวกเขาในที่สุดคุณจะต้องทำผิดพลาดและทำให้ความสมบูรณ์ของข้อมูลของคุณเสียหาย

พวกเขาไม่จำเป็นต้องพูดอย่างเคร่งครัด แต่ผลประโยชน์มีมาก

ฉันค่อนข้างมั่นใจว่าFogBugzไม่มีข้อ จำกัด ของ Foreign Key ในฐานข้อมูล ฉันสนใจที่จะได้ยินว่าทีมFog Creek Softwareจัดโครงสร้างโค้ดของพวกเขาอย่างไรเพื่อรับประกันว่าพวกเขาจะไม่นำเสนอความไม่สอดคล้องกัน

— เครา Eric Z
แหล่งที่มา

43

โจเอล: "จนถึงตอนนี้เราไม่เคยมีปัญหา" จนถึงตอนนี้ฉันไม่เคยขับรถเข้าไปในเสาไฟ แต่ฉันก็ยังคิดว่าควรคาดเข็มขัดนิรภัยนะคะ ;-)

— Tony Andrews

2

อาจเป็นเพราะคุณไม่เคยเห็นปัญหา แต่อาจเป็นที่นั่น ... ฐานข้อมูลส่วนใหญ่ใช้รูปแบบเช่น id_xxx ที่เหมือนกับ ixXXX

— FerranB

1

@ โจเอล: การตั้งชื่อแทนการบังคับใช้กฎ? เช่นกันอาจทำหายไปกับประเภทในขณะที่คุณอยู่ที่มัน

— jcollum

8

@ เอริก: คุณกำลังถือ Fog Creek เป็นอวตารของการพัฒนาซอฟต์แวร์ที่นี่ ถ้าคุณพูดว่า "บริษัท ในนิวยอร์กซิตี้ไม่มีคีย์ต่างประเทศในฐานข้อมูลของพวกเขา ... " เราทุกคนจะพูดว่า "และ?"

— jcollum

3

Eric: FogBugz ใช้หลักการตั้งชื่อสำหรับคีย์ต่างประเทศ ตัวอย่างเช่น ixBug เข้าใจว่าเป็นดัชนีในคีย์หลักของตาราง Bug จนถึงตอนนี้เราไม่เคยมีปัญหา - Joel Spolsky

— Sam Saffron

40

สคีมาฐานข้อมูลที่ไม่มีข้อ จำกัด FK ก็เหมือนกับการขับรถโดยไม่คาดเข็มขัดนิรภัย

วันหนึ่งคุณจะเสียใจ การไม่ใช้เวลาเพิ่มขึ้นเล็กน้อยกับพื้นฐานการออกแบบและความสมบูรณ์ของข้อมูลเป็นวิธีที่แน่นอนในการสร้างความปวดหัวในภายหลัง

คุณจะยอมรับรหัสในใบสมัครของคุณที่เลอะเทอะหรือไม่? ที่เข้าถึงอ็อบเจ็กต์สมาชิกโดยตรงและแก้ไขโครงสร้างข้อมูลโดยตรง

ทำไมคุณถึงคิดว่าสิ่งนี้ถูกทำให้ยากและเป็นที่ยอมรับไม่ได้ในภาษาสมัยใหม่

— ผู้ชาย
แหล่งที่มา

2

+1 สำหรับการเปรียบเทียบที่ดีระหว่างการห่อหุ้มและความสัมพันธ์ FK / PK

— jcollum

21

ใช่.

พวกเขาให้คุณซื่อสัตย์
พวกเขาให้ความซื่อสัตย์ต่อนักพัฒนาใหม่
คุณทำได้ ON DELETE CASCADE
ช่วยให้คุณสร้างไดอะแกรมที่สวยงามซึ่งอธิบายการเชื่อมโยงระหว่างตารางด้วยตนเอง

— csmba
แหล่งที่มา

1

ความซื่อสัตย์หมายถึงอะไร?

— dspacejs

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

— Oreste Viron

13

สมมติว่าโปรแกรมเมอร์กำลังทำสิ่งนี้ในลักษณะที่ถูกต้องอยู่แล้ว

การคิดเช่นนี้ดูเหมือนว่าฉันจะเป็นความคิดที่แย่มาก ในซอฟต์แวร์ทั่วไปมักมีปัญหา

และนั่นคือประเด็นจริงๆ นักพัฒนาไม่สามารถทำสิ่งที่ถูกต้องได้ดังนั้นการตรวจสอบให้แน่ใจว่าฐานข้อมูลไม่เต็มไปด้วยข้อมูลที่ไม่ดีจึงเป็นสิ่งที่ดี

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

— ดร. พิซซ่า
แหล่งที่มา

2

จุดที่ดีมันเป็นการดีที่จะรวมสองตารางด้วย "ON [Relationship]" หรือคีย์เวิร์ดอื่น ๆ และปล่อยให้ฐานข้อมูลระบุว่าเกี่ยวข้องกับคอลัมน์ใด ดูเหมือนจะสมเหตุสมผลจริงๆ

— jcollum

13

โดยส่วนตัวแล้วฉันชอบคีย์ต่างประเทศเพราะมันทำให้ความสัมพันธ์ระหว่างตารางเป็นทางการ ฉันตระหนักดีว่าคำถามของคุณสันนิษฐานว่าโปรแกรมเมอร์ไม่ได้แนะนำข้อมูลที่จะละเมิดความสมบูรณ์ของการอ้างอิง แต่ฉันได้เห็นหลายกรณีเช่นกันที่มีการละเมิดความสมบูรณ์ของข้อมูลอ้างอิงแม้ว่าจะมีเจตนาดีที่สุดก็ตาม!

ข้อ จำกัด ของคีย์ก่อนต่างประเทศ (aka declarative referential integrity หรือ DRI) ใช้เวลามากในการใช้ความสัมพันธ์เหล่านี้โดยใช้ทริกเกอร์ ความจริงที่ว่าเราสามารถทำให้ความสัมพันธ์เป็นทางการได้โดยการ จำกัด การประกาศนั้นมีพลังมาก

@John - ฐานข้อมูลอื่นอาจสร้างดัชนีสำหรับคีย์ต่างประเทศโดยอัตโนมัติ แต่ SQL Server ไม่ทำ ใน SQL Server ความสัมพันธ์ของคีย์ต่างประเทศเป็นเพียงข้อ จำกัด เท่านั้น คุณต้องกำหนดดัชนีของคุณบนคีย์ต่างประเทศแยกกัน (ซึ่งอาจเป็นประโยชน์)

แก้ไข: ฉันต้องการเพิ่มว่า IMO การใช้คีย์ต่างประเทศเพื่อรองรับ ON DELETE หรือ ON UPDATE CASCADE ไม่จำเป็นต้องเป็นสิ่งที่ดีเสมอไป ในทางปฏิบัติฉันพบว่าการเรียงซ้อนในการลบควรได้รับการพิจารณาอย่างรอบคอบโดยพิจารณาจากความสัมพันธ์ของข้อมูลเช่นคุณมีพ่อแม่ลูกตามธรรมชาติซึ่งอาจเป็นไปได้หรือตารางที่เกี่ยวข้องเป็นชุดของค่าการค้นหา การใช้การอัปเดตแบบเรียงซ้อนหมายความว่าคุณอนุญาตให้แก้ไขคีย์หลักของตารางหนึ่งตาราง ในกรณีนี้ฉันมีความขัดแย้งทางปรัชญาทั่วไปที่ไม่ควรเปลี่ยนคีย์หลักของตาราง คีย์ควรมีค่าคงที่โดยเนื้อแท้

— ปีเตอร์เมเยอร์
แหล่งที่มา

9

หากไม่มี Foreign Key คุณจะบอกได้อย่างไรว่าสองระเบียนในตารางต่างกันมีความสัมพันธ์กัน?

ฉันคิดว่าสิ่งที่คุณอ้างถึงคือความสมบูรณ์ของการอ้างอิงซึ่งไม่อนุญาตให้สร้างเรกคอร์ดลูกโดยไม่มีบันทึกหลักที่มีอยู่เป็นต้นสิ่งเหล่านี้มักเรียกว่าข้อ จำกัด ของคีย์ต่างประเทศ - แต่อย่าสับสนกับการมีอยู่ของคีย์ต่างประเทศใน ที่หนึ่ง.

— แซมจูสัน
แหล่งที่มา

8

การไม่มีคีย์ต่างประเทศมีประโยชน์หรือไม่? หากคุณไม่ได้ใช้ฐานข้อมูลแบบเส็งเคร็ง FKs ก็ไม่ยากที่จะตั้งค่า แล้วทำไมคุณถึงมีนโยบายที่จะหลีกเลี่ยงพวกเขา? เป็นสิ่งหนึ่งที่จะต้องมีหลักการตั้งชื่อที่ระบุว่าคอลัมน์อ้างอิงอีกคอลัมน์หนึ่งเป็นอีกสิ่งหนึ่งที่ต้องรู้ว่าฐานข้อมูลกำลังตรวจสอบความสัมพันธ์นั้นสำหรับคุณ

— Tundey
แหล่งที่มา

8

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

สมมติว่าโปรแกรมเมอร์กำลังทำสิ่งนี้ในลักษณะที่ถูกต้องอยู่แล้วเราต้องการแนวคิดของคีย์ต่างประเทศหรือไม่?

ในทางทฤษฎีไม่ อย่างไรก็ตามไม่เคยมีซอฟต์แวร์ชิ้นใดที่ไม่มีจุดบกพร่อง

โดยทั่วไปแล้วข้อบกพร่องในรหัสแอปพลิเคชันจะไม่เป็นอันตรายคุณระบุข้อบกพร่องและแก้ไขและหลังจากนั้นแอปพลิเคชันจะทำงานได้อย่างราบรื่นอีกครั้ง แต่ถ้าข้อผิดพลาดอนุญาตให้ข้อมูล currupt เข้าสู่ฐานข้อมูลแสดงว่าคุณติดอยู่กับมัน! การกู้คืนจากข้อมูลที่เสียหายในฐานข้อมูลนั้นยากมาก

พิจารณาว่าจุดบกพร่องเล็กน้อยในFogBugzอนุญาตให้เขียน Foreign Key ที่เสียหายในฐานข้อมูลหรือไม่ อาจเป็นเรื่องง่ายที่จะแก้ไขข้อบกพร่องและส่งการแก้ไขไปยังลูกค้าอย่างรวดเร็วในรุ่นแก้ไขข้อบกพร่อง อย่างไรก็ตามข้อมูลที่เสียหายในหลายสิบฐานข้อมูลควรได้รับการแก้ไขอย่างไร? ตอนนี้โค้ดที่ถูกต้องอาจพังทันทีเนื่องจากสมมติฐานเกี่ยวกับความสมบูรณ์ของคีย์ต่างประเทศไม่ได้รับการระงับอีกต่อไป

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

หากมีการเข้ารหัสข้อ จำกัด ในฐานข้อมูลสิ่งที่เลวร้ายที่สุดที่อาจเกิดขึ้นกับข้อบกพร่องคือผู้ใช้จะแสดงข้อความแสดงข้อผิดพลาดที่น่าเกลียดเกี่ยวกับข้อ จำกัด ของSQL ที่ไม่เป็นที่พอใจ วิธีนี้ดีกว่าที่จะปล่อยให้ข้อมูลที่เสียหายไปยังฐานข้อมูลองค์กรของคุณซึ่งจะทำให้แอปพลิเคชันทั้งหมดของคุณเสียหายหรือเพียงแค่นำไปสู่ผลลัพธ์ที่ผิดพลาดหรือทำให้เข้าใจผิดทุกประเภท

นอกจากนี้ข้อ จำกัด ของคีย์ต่างประเทศยังช่วยเพิ่มประสิทธิภาพเนื่องจากมีการจัดทำดัชนีตามค่าเริ่มต้น ฉันไม่สามารถนึกถึงเหตุผลใด ๆ ที่จะไม่ใช้ข้อ จำกัด ของคีย์ต่างประเทศ

— ฌาค
แหล่งที่มา

7

FKs มีความสำคัญมากและควรมีอยู่ในสคีของคุณจนกว่าคุณจะได้อีเบย์

— Cherouvim
แหล่งที่มา

2

ลิงค์นั้นน่าสนใจมากจริงๆ ... ฉันต้องการทราบรายละเอียดเพิ่มเติมจริงๆและฉันค่อนข้างกลัวที่จะใช้ ebay ตอนนี้ สำหรับคนอื่น ๆ : คลิกที่คำถามที่ 4 เพื่อดูว่าเขาพูดอะไรเกี่ยวกับโครงสร้างฐานข้อมูลของพวกเขา แม้ว่าการสัมภาษณ์ทั้งหมดจะน่าดู ด้วย ...unibrow

— gloomy.penguin

6

ฉันคิดว่าบางสิ่งในบางจุดต้องรับผิดชอบในการสร้างความสัมพันธ์ที่ถูกต้อง

ตัวอย่างเช่นRuby on Railsไม่ได้ใช้ Foreign Key แต่จะตรวจสอบความสัมพันธ์ทั้งหมดด้วยตัวมันเอง หากคุณเคยเข้าถึงฐานข้อมูลของคุณจากแอปพลิเคชัน Ruby on Rails นั่นก็ใช้ได้

อย่างไรก็ตามหากคุณมีไคลเอนต์อื่นที่กำลังเขียนไปยังฐานข้อมูลหากไม่มีคีย์ต่างประเทศก็จำเป็นต้องใช้การตรวจสอบความถูกต้องของตนเอง จากนั้นคุณจะมีสำเนารหัสตรวจสอบความถูกต้องสองชุดซึ่งมักจะแตกต่างกันซึ่งโปรแกรมเมอร์คนใดควรจะบอกได้ว่าเป็นบาปที่สำคัญ

เมื่อถึงจุดนั้นคีย์ต่างประเทศเป็นสิ่งที่จำเป็นมากเนื่องจากทำให้คุณสามารถย้ายความรับผิดชอบไปยังจุดเดียวได้อีกครั้ง

— Orion Edwards
แหล่งที่มา

2

มันเหมือนหัวหอม FK เป็นชั้นสุดท้ายของการป้องกัน หากไม่ใช่ฐานข้อมูลในเครื่องที่ฝังไว้แอปที่พยายามสร้างความสมบูรณ์ของการอ้างอิงเป็นความคิดที่ไม่ดีเสมอไป

— Fabricio Araujo

5

คีย์ต่างประเทศช่วยให้ผู้ที่ไม่เคยเห็นฐานข้อมูลของคุณมาก่อนสามารถกำหนดความสัมพันธ์ระหว่างตารางได้

ตอนนี้ทุกอย่างอาจเรียบร้อยดี แต่คิดว่าจะเกิดอะไรขึ้นเมื่อโปรแกรมเมอร์ของคุณจากไปและมีคนอื่นมารับช่วงต่อ

คีย์ต่างประเทศจะช่วยให้พวกเขาเข้าใจโครงสร้างฐานข้อมูลโดยไม่ต้องลากผ่านโค้ดนับพันบรรทัด

— เครก
แหล่งที่มา

5

เท่าที่ฉันรู้มีการใช้คีย์ต่างประเทศเพื่อช่วยโปรแกรมเมอร์ในการจัดการข้อมูลด้วยวิธีที่ถูกต้อง

FK ช่วยให้ DBA สามารถปกป้องความสมบูรณ์ของข้อมูลจากการคลำหาของผู้ใช้เมื่อโปรแกรมเมอร์ทำไม่สำเร็จและบางครั้งก็เพื่อป้องกันการคลำของโปรแกรมเมอร์

สมมติว่าโปรแกรมเมอร์กำลังทำสิ่งนี้ในลักษณะที่ถูกต้องอยู่แล้วเราต้องการแนวคิดของคีย์ต่างประเทศหรือไม่?

โปรแกรมเมอร์เป็นมนุษย์และเข้าใจผิด FK มีการเปิดเผยซึ่งทำให้พวกเขาเข้าใจยากขึ้น

มีการใช้คีย์ต่างประเทศอื่น ๆ หรือไม่? ฉันขาดอะไรที่นี่?

แม้ว่านี่จะไม่ใช่สาเหตุที่สร้างขึ้น แต่ FK ให้คำแนะนำที่เชื่อถือได้ที่แข็งแกร่งสำหรับเครื่องมือสร้างไดอะแกรมและเพื่อค้นหาผู้สร้าง สิ่งนี้ถูกส่งต่อไปยังผู้ใช้ปลายทางซึ่งต้องการคำแนะนำที่เชื่อถือได้อย่างมาก

— Peter Wone
แหล่งที่มา

นี่คือคำตอบที่ยอดเยี่ยม

— Dan Lugg

4

ไม่จำเป็นอย่างยิ่งโดยไม่จำเป็นต้องใช้เข็มขัดนิรภัยอย่างเคร่งครัด แต่พวกเขาสามารถช่วยคุณไม่ให้ทำอะไรโง่ ๆ ที่ทำให้ฐานข้อมูลของคุณเสียหายได้

การแก้ไขข้อผิดพลาดข้อ จำกัด FK ดีกว่าการสร้างการลบที่ทำให้แอปพลิเคชันของคุณเสียหาย

— มาร์คแฮร์ริสัน
แหล่งที่มา

4

สิ่งเหล่านี้มีความสำคัญเนื่องจากแอปพลิเคชันของคุณไม่ใช่วิธีเดียวที่สามารถจัดการข้อมูลในฐานข้อมูลได้ แอปพลิเคชันของคุณอาจจัดการกับความสมบูรณ์ของการอ้างอิงได้อย่างตรงไปตรงมาตามที่ต้องการ แต่สิ่งที่ต้องทำก็คือโบโซ่หนึ่งตัวที่มีสิทธิ์ที่เหมาะสมในการเข้ามาและออกคำสั่งแทรกลบหรืออัปเดตในระดับฐานข้อมูลและการบังคับใช้ความสมบูรณ์ของการอ้างอิงแอปพลิเคชันทั้งหมดของคุณจะถูกข้ามไป การใส่ข้อ จำกัด FK ในระดับฐานข้อมูลหมายความว่าหากไม่ให้โบโซนี้เลือกปิดใช้งานข้อ จำกัด FK ก่อนออกคำสั่งข้อ จำกัด FK จะทำให้คำสั่งแทรก / อัปเดต / ลบที่ไม่ดีล้มเหลวด้วยการละเมิดความสมบูรณ์ของการอ้างอิง

— ไมค์ McAllister
แหล่งที่มา

3

ผมคิดเกี่ยวกับเรื่องนี้ในแง่ของต้นทุน / ผลประโยชน์ ... ในMySQLเพิ่มข้อ จำกัด คือเส้นเพิ่มเติมเดียวของDDL คำสำคัญเพียงไม่กี่คำและความคิดไม่กี่วินาที นั่นคือ "ต้นทุน" เดียวในความคิดของฉัน ...

เครื่องมือชอบคีย์ต่างประเทศ คีย์ต่างประเทศป้องกันข้อมูลที่ไม่ดี (นั่นคือแถวที่ไม่มีผู้ดูแล) ซึ่งอาจไม่ส่งผลกระทบต่อตรรกะทางธุรกิจหรือฟังก์ชันการทำงานและไม่มีใครสังเกตเห็นและสร้างขึ้น นอกจากนี้ยังป้องกันไม่ให้นักพัฒนาที่ไม่คุ้นเคยกับสคีมาใช้งานชิ้นส่วนทั้งหมดโดยไม่ทราบว่าพวกเขาขาดความสัมพันธ์ บางทีทุกอย่างอาจยอดเยี่ยมภายในขอบเขตของแอปพลิเคชันปัจจุบันของคุณ แต่หากคุณพลาดบางสิ่งบางอย่างและสักวันมีการเพิ่มสิ่งที่ไม่คาดคิดเข้ามา (คิดว่าการรายงานแบบแฟนซี) คุณอาจอยู่ในจุดที่คุณต้องล้างข้อมูลที่ไม่ดีที่สะสมมาด้วยตนเองตั้งแต่เริ่มต้น ของสคีมาที่ไม่มีฐานข้อมูลบังคับใช้การตรวจสอบ

การใช้เวลาเพียงเล็กน้อยในการเขียนรหัสสิ่งที่อยู่ในหัวของคุณเมื่อคุณรวมสิ่งต่างๆเข้าด้วยกันสามารถช่วยคุณหรือคนอื่น ๆ ได้หลายเดือนหรือหลายปีที่เศร้าโศก

คำถาม:

มีการใช้คีย์ต่างประเทศอื่น ๆ หรือไม่? ฉันขาดอะไรที่นี่?

เป็นบิตโหลด แทรกความคิดเห็นการเยื้องหรือการตั้งชื่อตัวแปรแทน "คีย์ต่างประเทศ" ... หากคุณเข้าใจสิ่งที่เป็นปัญหาอย่างถ่องแท้แล้วคุณก็ "ไม่มีประโยชน์"

— danb
แหล่งที่มา

2

การลดเอนโทรปี ลดโอกาสที่จะเกิดสถานการณ์วุ่นวายในฐานข้อมูล เรามีช่วงเวลาที่ยากลำบากในการพิจารณาความเป็นไปได้ทั้งหมดดังนั้นในความคิดของฉันการลดเอนโทรปีเป็นกุญแจสำคัญในการบำรุงรักษาระบบใด ๆ

เมื่อเราทำการสมมติฐานตัวอย่างเช่น: สั่งซื้อแต่ละครั้งมีลูกค้าที่สมมติฐานควรจะบังคับใช้โดยบางสิ่งบางอย่าง ในฐานข้อมูลที่ "บางสิ่ง" เป็นคีย์ต่างประเทศ

ฉันคิดว่านี่เป็นสิ่งที่คุ้มค่ากับความเร็วในการพัฒนา แน่นอนว่าคุณสามารถเขียนโค้ดได้เร็วขึ้นเมื่อปิดและนี่อาจเป็นสาเหตุที่บางคนไม่ใช้ โดยส่วนตัวแล้วฉันได้ฆ่าไปหลายชั่วโมงด้วยNHibernateและข้อ จำกัด ของคีย์แปลกปลอมที่ทำให้ฉันโกรธเมื่อฉันดำเนินการบางอย่าง อย่างไรก็ตามฉันรู้ว่าปัญหาคืออะไรจึงเป็นปัญหาน้อยกว่า ฉันกำลังใช้เครื่องมือปกติและมีแหล่งข้อมูลที่จะช่วยฉันแก้ปัญหานี้อาจจะมีคนมาช่วยก็ได้!

อีกทางเลือกหนึ่งคืออนุญาตให้บั๊กเล็ดลอดเข้ามาในระบบ (และให้เวลาพอสมควร) โดยที่ไม่ได้ตั้งค่าคีย์ต่างประเทศและข้อมูลของคุณไม่สอดคล้องกัน จากนั้นคุณจะได้รับรายงานข้อบกพร่องที่ผิดปกติตรวจสอบและ "OH" ฐานข้อมูลถูกเมา ตอนนี้จะใช้เวลาแก้ไขนานแค่ไหน?

— Quibblesome
แหล่งที่มา

1

คุณสามารถดูคีย์ต่างประเทศเป็นข้อ จำกัด ที่

ช่วยรักษาความสมบูรณ์ของข้อมูล
แสดงว่าข้อมูลเกี่ยวข้องกันอย่างไร (ซึ่งสามารถช่วยในการบังคับใช้ตรรกะและกฎทางธุรกิจ)
หากใช้อย่างถูกต้องสามารถช่วยเพิ่มประสิทธิภาพในการดึงข้อมูลจากตารางได้

— ปาสคาล
แหล่งที่มา

1

ขณะนี้เราไม่ได้ใช้คีย์ต่างประเทศ และส่วนใหญ่เราไม่เสียใจเลย

ที่กล่าวว่า - เรามีแนวโน้มที่จะเริ่มใช้มันมากขึ้นในอนาคตอันใกล้ด้วยเหตุผลหลายประการทั้งสองอย่างด้วยเหตุผลที่คล้ายกัน:

ไดอะแกรม การสร้างแผนภาพของฐานข้อมูลจะง่ายกว่ามากหากมีการใช้ความสัมพันธ์ของคีย์ต่างประเทศอย่างถูกต้อง
การสนับสนุนเครื่องมือ การสร้างแบบจำลองข้อมูลโดยใช้Visual Studio 2008นั้นง่ายกว่ามากซึ่งสามารถใช้สำหรับLINQ เป็น SQL ได้หากมีความสัมพันธ์ของ Foreign Key ที่เหมาะสม

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

— จอห์นคริสเตนเซน
แหล่งที่มา

1

ฉันทำงานกับระบบที่ไม่ได้ใช้ และฉันเสียใจเป็นประจำ ฉันได้เห็นหลายกรณีที่ฉันสามารถนับข้อมูลที่ไม่สมเหตุสมผลซึ่งจะถูกป้องกันโดยข้อ จำกัด ที่เหมาะสม

— ซ้ำ

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

— John Christensen

1

สิ่งที่ดีที่สุดเกี่ยวกับข้อ จำกัด ของคีย์ต่างประเทศ (และข้อ จำกัด โดยทั่วไปจริงๆ) คือคุณสามารถพึ่งพาได้เมื่อเขียนข้อความค้นหาของคุณ ข้อความค้นหาจำนวนมากอาจซับซ้อนขึ้นได้มากหากคุณไม่สามารถพึ่งพาโมเดลข้อมูลที่ถือเป็น "จริง" ได้

ในโค้ดโดยทั่วไปเราจะได้รับข้อยกเว้นที่เกิดขึ้นที่ไหนสักแห่ง - แต่ในSQLโดยทั่วไปเราจะได้รับคำตอบที่ "ผิด"

ตามทฤษฎีแล้วSQL Serverสามารถใช้ข้อ จำกัด เป็นส่วนหนึ่งของแผนการสืบค้นได้ แต่ยกเว้นข้อ จำกัด ในการตรวจสอบสำหรับการแบ่งพาร์ติชันฉันไม่สามารถพูดได้ว่าฉันเคยเห็นสิ่งนั้นมาก่อน

— มาร์ค Brackett
แหล่งที่มา

ข้อ จำกัด ของความเป็นเอกลักษณ์บ่งบอกถึงความมีคาร์ดินัลสูงซึ่งเครื่องมือเพิ่มประสิทธิภาพใช้ในการเลือกกลไกการเข้าร่วม

— Peter Wone

1

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

แต่มักจะมีรูปแบบของการตั้งชื่อคอลัมน์ซึ่งเป็นคีย์ต่างประเทศ

เช่นเดียวกับการทำให้เป็นมาตรฐานฐานข้อมูล - คุณต้องรู้ว่าคุณกำลังทำอะไรอยู่และผลของสิ่งนั้นคืออะไร (ประสิทธิภาพส่วนใหญ่)

ฉันตระหนักถึงข้อดีของคีย์ต่างประเทศ (ความสมบูรณ์ของข้อมูลดัชนีสำหรับคอลัมน์คีย์ต่างประเทศเครื่องมือที่ทราบสคีมาฐานข้อมูล) แต่ฉันก็กลัวที่จะใช้คีย์ต่างประเทศตามกฎทั่วไป

นอกจากนี้เอ็นจิ้นฐานข้อมูลต่างๆยังสามารถให้บริการคีย์ต่างประเทศในลักษณะที่แตกต่างออกไปซึ่งอาจนำไปสู่ข้อบกพร่องที่ละเอียดอ่อนระหว่างการย้ายข้อมูล

การลบคำสั่งซื้อและใบแจ้งหนี้ทั้งหมดของไคลเอนต์ที่ถูกลบด้วย ON DELETE CASCADE เป็นตัวอย่างที่สมบูรณ์แบบของสคีมาฐานข้อมูลที่ดูดี แต่ออกแบบผิด

— Grzegorz Gierlik
แหล่งที่มา

0

ใช่. ON DELETE [RESTRICT | CASCADE] ช่วยให้นักพัฒนาไม่ต้องผูกข้อมูลทำให้ข้อมูลสะอาด ฉันเพิ่งเข้าร่วมทีมนักพัฒนา Rails ที่ไม่ได้มุ่งเน้นไปที่ข้อ จำกัด ของฐานข้อมูลเช่นคีย์ต่างประเทศ

โชคดีที่ฉันพบสิ่งเหล่านี้: http://www.redhillonrails.org/foreign_key_association.html - ปลั๊กอิน RedHill on Ruby on Rails สร้างคีย์ต่างประเทศโดยใช้การประชุมผ่านรูปแบบการกำหนดค่า การย้ายข้อมูลด้วยproduct_idจะสร้างคีย์นอกให้กับidในตาราง ผลิตภัณฑ์

ตรวจสอบปลั๊กอินที่ยอดเยี่ยมอื่น ๆ ที่RedHillรวมถึงการย้ายข้อมูลที่รวมอยู่ในธุรกรรม

— ปีเตอร์มอร์เทนเซน
แหล่งที่มา

0

หากคุณวางแผนที่จะสร้างรหัสการเข้าถึงข้อมูลของคุณเช่น Entity Framework หรือ ORM อื่น ๆ คุณจะสูญเสียความสามารถในการสร้างแบบจำลองลำดับชั้นโดยไม่มี Foreign Keys

— ไมค์กริฟฟิน
แหล่งที่มา