เคยมีเวลาบ้างไหมที่ใช้ความสัมพันธ์แบบ 1: 1 กับฐานข้อมูล

162

ฉันคิดถึงวันธรรมดาในการทำให้เป็นมาตรฐานและมันเกิดขึ้นกับฉันฉันไม่สามารถนึกถึงเวลาที่ควรมีความสัมพันธ์แบบ 1: 1 ในฐานข้อมูล

Name:SSN? ฉันต้องการพวกเขาในตารางเดียวกัน
PersonID:AddressID? อีกครั้งตารางเดียวกัน

ฉันสามารถสร้างตัวอย่างที่มีค่าเป็นล้าน ๆ ได้คือ 1: มากหรือมาก: มาก (พร้อมโต๊ะกลางที่เหมาะสม) แต่ไม่เคยเป็น 1: 1

ฉันขาดอะไรที่ชัดเจนหรือไม่

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

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

— Pacerier

และเป็นคำถามที่ติดตามถ้ามันไม่ทำให้รู้สึกว่าจะทำหรือไม่ พิจารณาที่นี่และที่นี่ - คำถามของฉันคือวิธีการเลือก 2 ตารางใดที่มีข้อ จำกัด Foreign Key? ฉันเดาว่ามันขึ้นอยู่กับกรณีการใช้งานที่คุณกำลังพยายามจัดการ ...

— The Red Pea

161

โดยทั่วไปความสัมพันธ์แบบ 1: 1 บ่งชี้ว่าคุณได้แบ่งพาร์ติชันเอนทิตีที่ใหญ่กว่าด้วยเหตุผลบางประการ บ่อยครั้งเป็นเพราะเหตุผลด้านประสิทธิภาพใน schema ทางกายภาพ แต่อาจเกิดขึ้นในด้านตรรกะเช่นกันหากคาดว่าข้อมูลจำนวนมากเป็น "ไม่ทราบ" ในเวลาเดียวกัน (ในกรณีที่คุณมี 1: 0 หรือ 1: 1 แต่ไม่มาก)

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

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

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

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

32

ตัวอย่างที่สมบูรณ์แบบของสิ่งนี้อาจเป็นตารางที่มีไฟล์ คุณอาจต้องการมีหนึ่งตารางที่มีเพียงข้อมูลเมตาของไฟล์ (ชื่อไฟล์ประเภท mime ฯลฯ ) และอีกตารางหนึ่งซึ่งแมป 1: 1 ซึ่งมีข้อมูลหยดจริง สิ่งนี้จะลดค่าใช้จ่ายในการสืบค้น / เรียงลำดับไฟล์ในบางกรณี

— Kevin Peno

2

ใช่. มันขึ้นอยู่กับฐานข้อมูล (การออกแบบที่ทันสมัยมีการจัดเก็บ blobs ในระบบไฟล์โดยใช้ประเภทที่ถูกต้อง) และแม้จะมีการสนับสนุนดังกล่าวจะต้องระมัดระวังในการแยกคอลัมน์ (ในรายการคอลัมน์ SQL ชัดเจนเป็นเรื่องปกติ แต่ ORM บางตัวต้องการลาก บันทึกทั้งหมด) เคล็ดลับคือการรู้จักรูปแบบการใช้งานของคุณ: หากส่วนใหญ่แล้วข้อมูลจริงจะถูกละเว้นฉันจะใช้ตาราง 1: 1 หยด หากการเข้าถึงส่วนใหญ่เป็นการดาวน์โหลดข้อมูลฉันจะใช้กลไกการจัดเก็บแบบเนทีฟ

— Godeke

@Ochado ในขณะที่ฉันยอมรับว่าคุณมีเหตุผลหลายประการที่เกิดขึ้นตามธรรมชาติ (ไม่ใช่ทางกายภาพ) สำหรับ 1: 1, cavate "ถ้าคุณไม่มีข้อมูลทางประวัติศาสตร์" ทำให้กรณีเหล่านั้นที่ฉันอาจจะไม่ใช้ความสัมพันธ์ 1: 1 ถึง บังคับใช้

— Godeke

1

@Ochado ฉันคิดว่าความสัมพันธ์ของ IS-A เป็นตัวอย่างที่ดีอย่างไรก็ตาม ฉันพยายามหลีกเลี่ยงการพยายามบังคับแนวคิดเชิงวัตถุในตารางของฉัน (แทนที่จะใช้ ORM เป็นคลังข้อมูล) แต่ฉันเห็นกรณีที่ฉันถูกล่อลวง ประสิทธิภาพของระบบดังกล่าวในระดับฆ่าการทดลองเหล่านั้น ถึงกระนั้นนั่นก็อาจเป็นตัวอย่างที่ดีที่สุดของตัวอย่างที่ไม่เกี่ยวข้องกับประสิทธิภาพ

— Godeke

จริงๆแล้ว IS-A และสถานการณ์การจองที่ตรงกันน่าจะยังคงอยู่ที่ 1: 1 แม้ว่าข้อมูลประวัติจะถูกเก็บไว้ก็ตาม

— Tripartio

125

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

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

บล็อกของฉันเกี่ยวกับมัน

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

47

การกระจัดกระจาย ความสัมพันธ์ของข้อมูลอาจเป็นเทคนิค 1: 1 แต่แถวที่เกี่ยวข้องไม่จำเป็นต้องมีอยู่สำหรับทุกแถว ดังนั้นถ้าคุณมียี่สิบล้านแถวและมีชุดของค่าบางอย่างที่มีอยู่เพียง 0.5% ของการประหยัดพื้นที่นั้นมีมากมายถ้าคุณผลักคอลัมน์เหล่านั้นออกไปยังตารางที่สามารถมีประชากรเบาบาง

— ความสับสนวุ่นวาย
แหล่งที่มา

8

"แต่ไม่จำเป็นต้องมีแถวที่เกี่ยวข้องสำหรับทุกแถว" จากนั้นไม่ใช่ 1: 1 คุณกำลังพูดถึง 1: 0,1

1

ใช่. Dunno ถ้า OP ดึงความแตกต่างออกมา

— ความวุ่นวาย

2

ฉันคิดว่าพวกเขาทำเพราะ 1: 0,1 มีการใช้งานมากมายรวมถึงของคุณ แต่ 1: 1 มีน้อยกว่ามาก และพวกเขากำลังดิ้นรนเพื่อหาประโยชน์ดังนั้นฉันจึงบอกว่า OP กำลังวาดความแตกต่าง

12

สมมติฐานการทำงานของฉันตรงกันข้ามเพราะเขาระบุ 1: 1, 1: มากมายและอีกมากมาย: หลายคนโดยไม่พูดถึง 1: 0,1

— ความวุ่นวาย

26

คำตอบที่ได้รับการจัดอันดับสูงส่วนใหญ่ให้การปรับแต่งฐานข้อมูลที่มีประโยชน์มากและเหตุผลในการปรับให้เหมาะสมสำหรับความสัมพันธ์แบบ 1: 1 แต่ฉันต้องการที่จะมุ่งเน้นไปที่ตัวอย่างใด ๆ

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

"Is-A" หรือความสัมพันธ์ supertype / subtype หรือการสืบทอด / การจำแนกประเภท: หมวดหมู่นี้เมื่อเอนทิตีหนึ่งเป็นประเภทเฉพาะของเอนทิตีอื่น ตัวอย่างเช่นอาจมีนิติบุคคลพนักงานที่มีคุณลักษณะที่ใช้กับพนักงานทุกคนและจากนั้นหน่วยงานที่แตกต่างกันเพื่อระบุประเภทของพนักงานที่มีคุณลักษณะเฉพาะสำหรับพนักงานประเภทนั้นเช่นแพทย์นักบัญชีนักบิน ฯลฯ การออกแบบนี้จะหลีกเลี่ยงค่า null หลายค่าตั้งแต่ พนักงานหลายคนจะไม่ได้มีคุณสมบัติเฉพาะของประเภทย่อยที่เฉพาะเจาะจง ตัวอย่างอื่น ๆ ในหมวดหมู่นี้อาจเป็นผลิตภัณฑ์เป็น supertype และ ManufacturingProduct และ MaintenanceSupply เป็นชนิดย่อย สัตว์เป็นซุปเปอร์ประเภทและสุนัขและแมวเป็นชนิดย่อย; เป็นต้นโปรดทราบว่าเมื่อใดก็ตามที่คุณพยายามแมปลำดับชั้นการสืบทอดเชิงวัตถุลงในฐานข้อมูลเชิงสัมพันธ์ (เช่นในโมเดลเชิงสัมพันธ์เชิงวัตถุ) นี่คือความสัมพันธ์ชนิดหนึ่งที่แสดงถึงสถานการณ์ดังกล่าว
ความสัมพันธ์ "บอส"เช่นผู้จัดการประธานประธาน ฯลฯ ที่หน่วยองค์กรสามารถมีเจ้านายได้เพียงคนเดียวและบุคคลหนึ่งคนสามารถเป็นหัวหน้าของหน่วยองค์กรเดียวได้ หากกฎเหล่านั้นมีผลบังคับใช้แสดงว่าคุณมีความสัมพันธ์แบบ 1: 1 เช่นผู้จัดการหนึ่งคนแผนกหนึ่ง CEO ของ บริษัท ฯลฯ ความสัมพันธ์ "บอส" ไม่เพียง แต่ใช้กับคนเท่านั้น ความสัมพันธ์แบบเดียวกันนี้เกิดขึ้นหากมีร้านค้าเพียงร้านเดียวที่เป็นสำนักงานใหญ่ของ บริษัท หรือถ้ามีเพียงเมืองเดียวคือเมืองหลวงของประเทศ
การจัดสรรทรัพยากรที่ขาดแคลนบางประเภทเช่นพนักงานหนึ่งคนสามารถมอบหมายให้ บริษัท หนึ่งคันได้พร้อมกัน (เช่นรถบรรทุกหนึ่งคันต่อรถบรรทุกหนึ่งคันรถแท็กซี่ต่อคนขับรถแท็กซี่หนึ่งคัน ฯลฯ ) เพื่อนร่วมงานให้ฉันตัวอย่างนี้เมื่อเร็ว ๆ นี้
การแต่งงาน (อย่างน้อยในเขตอำนาจศาลที่กฎหมายซึ่งมีสามีเป็นสิ่งผิดกฎหมาย): บุคคลหนึ่งคนสามารถแต่งงานกับบุคคลอื่นได้เพียงคนเดียวในแต่ละครั้ง ฉันได้รับตัวอย่างจากหนังสือเรียนที่ใช้สิ่งนี้เป็นตัวอย่างของความสัมพันธ์แบบเอกภาพ 1: 1 เมื่อ บริษัท บันทึกการแต่งงานระหว่างพนักงาน
การจับคู่การจอง : เมื่อทำการจองที่ไม่ซ้ำกันแล้วทำให้เป็นสองเอนทิตีแยกกัน ตัวอย่างเช่นระบบเช่ารถอาจบันทึกการจองในหนึ่งเอนทิตีและจากนั้นเป็นการเช่าจริงในเอนทิตีที่แยกต่างหาก แม้ว่าสถานการณ์ดังกล่าวสามารถออกแบบเป็นเอนทิตี้เดียวได้ แต่ก็ควรแยกจากเอนทิตีเนื่องจากการจองไม่สมบูรณ์และไม่ใช่ทุกการเช่าต้องมีการจองและทั้งสองสถานการณ์เป็นเรื่องธรรมดามาก

ฉันย้ำข้อแม้ที่ฉันทำไว้ก่อนหน้านี้ว่าสิ่งเหล่านี้ส่วนใหญ่เป็นความสัมพันธ์แบบ 1: 1 ต่อเมื่อไม่มีการบันทึกข้อมูลในอดีต ดังนั้นหากพนักงานเปลี่ยนบทบาทในองค์กรหรือผู้จัดการรับผิดชอบแผนกอื่นหรือพนักงานถูกกำหนดยานพาหนะใหม่หรือมีคนม่ายและแต่งงานใหม่ผู้เข้าร่วมความสัมพันธ์ก็สามารถเปลี่ยนได้ หากฐานข้อมูลไม่ได้จัดเก็บประวัติก่อนหน้าใด ๆ เกี่ยวกับความสัมพันธ์แบบ 1: 1 แสดงว่าพวกเขายังคงมีความสัมพันธ์แบบ 1: 1 ที่ถูกกฎหมาย แต่ถ้าฐานข้อมูลบันทึกข้อมูลในอดีต (เช่นการเพิ่มวันที่เริ่มต้นและวันที่สิ้นสุดสำหรับแต่ละความสัมพันธ์) แล้วพวกเขาก็จะกลายเป็นความสัมพันธ์ M: M

มีข้อยกเว้นที่น่าสังเกตสองประการเกี่ยวกับบันทึกทางประวัติศาสตร์: ประการแรกความสัมพันธ์บางอย่างเปลี่ยนไปบ่อยครั้งที่ข้อมูลในอดีตจะไม่ถูกจัดเก็บ ตัวอย่างเช่นความสัมพันธ์ IS-A ส่วนใหญ่ (เช่นประเภทผลิตภัณฑ์) นั้นไม่เปลี่ยนรูป นั่นคือพวกเขาไม่สามารถเปลี่ยนแปลงได้ ดังนั้นจุดบันทึกประวัติศาสตร์คือ moot; สิ่งเหล่านี้จะถูกนำมาใช้เป็นความสัมพันธ์ตามธรรมชาติ 1: 1 เสมอ ประการที่สองร้านขายของความสัมพันธ์สำรองห้องพักแยกจากกันเนื่องจากการจองและการเช่าเป็นกิจกรรมอิสระแต่ละแห่งมีวันที่ของตนเอง เนื่องจากเอนทิตีมีวันที่ของตัวเองแทนที่จะเป็นความสัมพันธ์ 1: 1 ซึ่งมีวันที่เริ่มต้นสิ่งเหล่านี้จะยังคงเป็นความสัมพันธ์แบบ 1: 1 แม้ว่าข้อมูลประวัติจะถูกเก็บไว้

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

2

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

— user1852503

21

คำถามของคุณสามารถตีความได้หลายวิธีเพราะวิธีที่คุณใช้พูด คำตอบแสดงให้เห็นสิ่งนี้

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

แต่ฉันคิดว่าสิ่งที่คุณถามจริง ๆ คือ ... เมื่อมีความสัมพันธ์แบบ 1: 1 ตารางจะต้องถูกแยกออกหรือไม่ คุณควรมีตารางสองตารางที่มีคีย์เหมือนกันหรือไม่? ในทางปฏิบัติเราส่วนใหญ่วิเคราะห์เฉพาะคีย์หลักและไม่ใช่คีย์ตัวเลือกอื่น ๆ แต่คำถามนั้นแตกต่างกันเล็กน้อย

กฎการทำให้เป็นมาตรฐานสำหรับ 1NF, 2NF และ 3NF ไม่จำเป็นต้องแยกย่อย (แยก) ตารางออกเป็นสองตารางด้วยคีย์หลักเดียวกัน ฉันไม่ได้คิดออกว่าวางสคีมาใน BCNF, 4NF หรือ 5NF สามารถส่งผลให้สองตารางด้วยปุ่มเดียวกัน จากด้านบนของหัวฉันจะเดาว่าคำตอบคือไม่

มีระดับของการฟื้นฟูที่เรียกว่า 6NF กฎการนอร์มัลไลซ์เซชั่นสำหรับ 6NF สามารถส่งผลให้มีสองตารางด้วยคีย์หลักเดียวกัน 6NF มีข้อได้เปรียบมากกว่า 5NF ที่สามารถหลีกเลี่ยง NULLS ได้อย่างสมบูรณ์ นี่เป็นสิ่งสำคัญสำหรับนักออกแบบฐานข้อมูลบางคน แต่ไม่ใช่ทั้งหมด ฉันไม่เคยใส่ใจที่จะใส่สคีมาใน 6NF

ใน 6NF ข้อมูลที่ขาดหายไปสามารถถูกแทนด้วยแถวที่ถูกข้ามแทนที่จะเป็นแถวที่มีค่า NULL ในบางคอลัมน์

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

— Walter Mitty
แหล่งที่มา

19

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

โปสเตอร์อื่นให้ความเห็นเกี่ยวกับ 1: 1 ที่ไม่ได้ทำให้เป็นมาตรฐานฉันจะไม่เห็นด้วยกับมันในบางสถานการณ์โดยเฉพาะอย่างยิ่งการพิมพ์ย่อย สมมติว่าฉันมีตารางพนักงานและคีย์หลักคือ SSN ของพวกเขา (เป็นตัวอย่างลองบันทึกการอภิปรายว่านี่เป็นคีย์ที่ดีหรือไม่สำหรับเธรดอื่น) พนักงานสามารถเป็นประเภทที่แตกต่างกันพูดชั่วคราวหรือถาวรและถ้าพวกเขาถาวรพวกเขามีฟิลด์เพิ่มเติมที่จะกรอกเช่นหมายเลขโทรศัพท์สำนักงานซึ่งควรจะไม่เป็นโมฆะถ้า type = 'ถาวร' ในฐานข้อมูลปกติรูปแบบที่ 3 คอลัมน์ควรขึ้นอยู่กับคีย์ซึ่งหมายถึงพนักงาน แต่จริงๆแล้วมันขึ้นอยู่กับพนักงานและประเภทดังนั้นความสัมพันธ์ 1: 1 จึงเป็นเรื่องปกติอย่างสมบูรณ์และเป็นที่ต้องการในกรณีนี้ นอกจากนี้ยังป้องกันตารางกระจัดกระจายมากเกินไปหากฉันมี 10 คอลัมน์ที่เต็มไปด้วยตามปกติ

— Shane Delmore
แหล่งที่มา

1

@ShaneD +1 สำหรับตัวอย่างคำศัพท์จริง ฉันชอบความแตกต่าง "อ่านอย่างเดียว"

— Michael Riley - AKA Gunny

13

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

— Erik Funkenbusch
แหล่งที่มา

อย่างจริงจัง? โดยทั่วไปแล้วไม่ใช่วิธีที่ดีที่สุด? ผู้จัดจำหน่ายเพลงออนไลน์รายใหญ่ที่สุดรายหนึ่งเก็บไว้ในฐานข้อมูล

1

@ Mark มีคำถามสองสามข้อที่จัดการกับวิธีที่ดีที่สุดในการจัดเก็บรูปภาพไม่ว่าจะในฐานข้อมูลหรือนอกและฉันทามติดูเหมือนว่าส่วนใหญ่แล้วระบบไฟล์จะเร็วกว่า ฉันคิดว่าถ้ามันเป็นจริงจริง ๆ แล้วสิ่งนั้นจะเป็นจริงสำหรับ MP3

— James McMahon

1

"โดยปกติแล้วคุณต้องการ BLOB ในตารางแยกต่างหาก" - โดยปกติ BLOB จะไม่ถูกจัดเก็บแบบอินไลน์ (หากเกินความยาวแถวเฉพาะของ DB) BLOBs หากไม่ใช่แบบอินไลน์มักจะถูกเก็บไว้เป็น 'ตัวชี้' ไปยังตำแหน่งทางกายภาพในหน้า DB

— blispr

1

เป็นที่ถกเถียงกันอยู่ว่ามันสมเหตุสมผลหรือไม่ที่จะเก็บข้อมูลขนาดใหญ่ (ไฟล์) ไว้ในฐานข้อมูลบางอันมีสาเหตุมาจากทั้งหมดที่มีเหตุผลที่ถูกต้อง แต่ +1 สำหรับตัวอย่างของ 1: 1

— Kevin Peno

นี่ควรเป็นคำถามของตัวเองที่ฉันอยากเห็น ด้วยการป้อนข้อมูลจากคนฉลาดที่วัดเวลา / prestanda สำหรับ harddrives ที่แตกต่างกัน / OS / RDBMS ควรจะมีคำตอบที่ชัดเจนสำหรับคำถามนี้มันไม่ควรเถียงถ้าวัดอย่างถูกต้อง ยังไม่ได้ทำอะไรเลยหรอกเหรอ?

— Stefan

9

ในแง่ของวิทยาศาสตร์บริสุทธิ์ใช่มันไร้ประโยชน์

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

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

3

@ Mark Brady: ไม่ไม่ได้เพราะมี Na2SO4 และ KCl เมื่อสร้างฐานข้อมูลจักรวาลคุณควรสร้าง t_atom (id INT, โปรตอน INT, นิวตรอน INT), t_molecule (id INT, atom_id INT) และทำการเชื่อม มันเป็นความสัมพันธ์แบบหนึ่งต่อหลายคน

— Quassnoi

2

ในความคิดที่สอง INT อาจไม่พอเพียงที่นี่เนื่องจากมี 10 ^ 78 อะตอมในจักรวาล แม้แต่ GUID สองตัวที่ติดกันสามารถยึดอะตอมได้เพียง 1 ใน 10 เราจะต้องมีคีย์หลัก RAW (40) - ในกรณีที่ฐานข้อมูลของเราจะเติบโตเร็วเกินไป สสารมืดบางสิ่งบางอย่าง

— Quassnoi

1

โอ้ทฤษฎีเชิงสัมพันธ์เท่านั้นที่เป็นวิทยาศาสตร์บริสุทธิ์ ไม่ทราบว่าเคมีไม่ใช่วิทยาศาสตร์ที่บริสุทธิ์เว้นแต่เราจะสร้างฐานข้อมูลไว้

1

@ Mark Brady: คุณไม่สามารถโปรดแค่พูดในสิ่งที่คุณไม่เห็นด้วยกับ? ฉันไม่ได้รับการเสียดสีของคุณจริงๆ :)

— Quassnoi

Quassnoi (และ Mark Brady) คุณได้รับ upvote สำหรับ LOL ที่คุณเพิ่งให้ฉัน

— Pulsehead

8

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

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

8

ฉันสามารถนึกถึงสถานการณ์ที่คุณมีแบบจำลอง OO ที่คุณใช้การสืบทอดและต้นไม้การสืบทอดจะต้องคงอยู่กับฐานข้อมูล

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

ในกรณีนี้คุณไม่จำเป็นต้องมีตาราง Animal หนึ่งตารางซึ่งมีคอลัมน์ nullable จำนวนมากเพื่อเก็บคุณสมบัติ Bird และ Fish โดยที่คอลัมน์ทั้งหมดที่มีข้อมูล Fish ถูกตั้งค่าเป็น NULL เมื่อระเบียนแสดงถึงนก

แต่คุณมีบันทึกในตารางนกที่มีความสัมพันธ์แบบหนึ่งต่อหนึ่งกับระเบียนในตารางสัตว์

— Frederik Gheysels
แหล่งที่มา

คำตอบนี้เกี่ยวข้องกับคำถามอื่น: ความสัมพันธ์ 1 ถึง 0‑1

— Hibou57

8

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

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

6

นอกจากนี้ยังเป็นวิธีที่จะขยายตารางที่มีอยู่แล้วในการผลิตที่มีความเสี่ยงน้อย (รับรู้) กว่าการเปลี่ยนแปลงฐานข้อมูล "ของจริง" การเห็นความสัมพันธ์แบบ 1: 1 ในระบบเดิมมักเป็นตัวบ่งชี้ที่ดีว่าฟิลด์ถูกเพิ่มหลังจากการออกแบบเริ่มต้น

— JT Grimes
แหล่งที่มา

ทำไมต้องแยกจากกัน? คุณคิดว่าแบรนด์ spankin ใหม่มีความเสี่ยงมากเท่ากับการเปลี่ยนแปลงตารางที่มีอยู่ กรุณาระบุรายการที่จะแตกเมื่อมีการเพิ่มตารางใหม่ สิ่งเดียวที่ฉันนึกได้ก็คือโค้ดที่ทำงานบนเมตาดาต้าเช่น SELECT * จาก USER_TABLES loop <something> end loop

1

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

— JT Grimes

@ Mark Brady ชุดข้อมูลที่พิมพ์ออกมาอย่างรุนแรงอาจเป็นนรกในการจัดการเมื่อเพิ่ม fileds สองสามรายการในฐานข้อมูล หาก tableadapter ในชุดข้อมูลนั้นมีหลายแบบสอบถามและอื่น ๆ มันง่ายมากที่จะเพียงแค่ลากในตารางใหม่แล้วทำมัน

— Stefan

@Stefan: ไม่มีการแทรกแบบเรียงซ้อน

— JT Grimes

@Bofof เอ่อ .. บางครั้งเราต้องใช้แป้นพิมพ์และโปรแกรมเล็กน้อยสำหรับเงินที่เราได้รับ ;)

— Stefan

5

ใน SQL เป็นไปไม่ได้ที่จะบังคับใช้ความสัมพันธ์แบบ 1: 1 ระหว่างสองตารางที่จำเป็นสำหรับทั้งสองด้าน (ยกเว้นว่าตารางนั้นเป็นแบบอ่านอย่างเดียว) เพื่อการปฏิบัติส่วนใหญ่ความสัมพันธ์ "1: 1" ใน SQL หมายถึง 1: 0 | 1

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

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

4

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

— Jason Punyon
แหล่งที่มา

3

เศร้าเหตุผลที่น่าเศร้า ถ้า ORM ไม่สามารถจัดการกับความแตกต่างระหว่างโมเดลวัตถุและหน่วยเก็บข้อมูลจริงได้แล้ว ... แค่เศร้า

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

— Tripartio

4

ฉันได้พบว่าเมื่อฉันทำความสัมพันธ์แบบ 1: 1 โดยสิ้นเชิงด้วยเหตุผลเชิงระบบไม่ใช่เหตุผลเชิงสัมพันธ์

ตัวอย่างเช่นฉันพบว่าการวางแง่มุมที่สงวนไว้ของผู้ใช้ใน 1 ตารางและการวางฟิลด์ที่ผู้ใช้สามารถแก้ไขได้ของผู้ใช้ในตารางที่แตกต่างกันช่วยให้การเขียนกฎเหล่านั้นอย่างมีเหตุผลเกี่ยวกับการอนุญาตบนฟิลด์เหล่านั้นง่ายขึ้นมาก

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

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

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

1

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

— DevelopingChris

@DevelopingChris ฉันเห็นด้วยว่า 1: 1 เป็นฟีโนโมน ยกเว้นทฤษฎีโรงเรียนมีสถานการณ์โลกจริงน้อยมากที่มีอยู่

— Michael Riley - AKA Gunny

4

ส่วนใหญ่แล้วการออกแบบนั้นคิดว่าเป็น 1: 1 จนกว่าจะมีคนถามว่า "ดีทำไมไม่เป็น 1: หลายคน"? การหย่าร้างแนวคิดจากคนอื่นก่อนเวลาอันควรจะทำในการคาดการณ์สถานการณ์ทั่วไปนี้ บุคคลและที่อยู่ไม่ผูกแน่น ผู้คนจำนวนมากมีที่อยู่หลายแห่ง และอื่น ๆ ...

โดยปกติแล้วการแยกวัตถุสองครั้งนั้นหมายความว่าหนึ่งหรือทั้งสองสามารถคูณได้ (x: มาก) หากวัตถุสองชิ้นเป็นจริงอย่างแท้จริง 1: 1 แม้แต่ในเชิงปรัชญานั่นก็คือความสัมพันธ์มากกว่า "วัตถุ" ทั้งสองนี้เป็นส่วนหนึ่งของวัตถุทั้งหมด

— Mark Canlas
แหล่งที่มา

3

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

— Ryan Guill
แหล่งที่มา

2

บ่อยที่สุดมันเป็นของทางกายภาพมากกว่าการสร้างตรรกะ โดยทั่วไปจะใช้เพื่อแบ่งพาร์ติชันตารางในแนวตั้งเพื่อใช้ประโยชน์จากการแบ่ง I / O ผ่านอุปกรณ์ทางกายภาพหรือการเพิ่มประสิทธิภาพการสืบค้นอื่น ๆ ที่เกี่ยวข้องกับการแยกข้อมูลหรือข้อมูลที่เข้าถึงบ่อยน้อยกว่าที่ต้องการรักษาความปลอดภัยมากกว่าแอตทริบิวต์ที่เหลือในวัตถุเดียวกัน (SSN เงินเดือน ฯลฯ )

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

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

2

เหตุผลที่ดีที่สุดที่ฉันเห็นความสัมพันธ์แบบ 1: 1 คือ SuperType SubType ของการออกแบบฐานข้อมูล ฉันสร้างโครงสร้างข้อมูล MLS ของอสังหาริมทรัพย์ตามโมเดลนี้ มีฟีดข้อมูลที่แตกต่างกันห้าแบบ ที่อยู่อาศัย, เชิงพาณิชย์, หลายครอบครัว, โรงแรมและที่ดิน

ฉันสร้าง SuperType เรียกว่าคุณสมบัติที่มีข้อมูลซึ่งเป็นเรื่องปกติสำหรับฟีดข้อมูลที่แยกจากกันห้ารายการ สิ่งนี้อนุญาตสำหรับการค้นหา "ง่าย" ที่รวดเร็วมากในทุกประเภทข้อมูล

ฉันสร้างประเภทย่อยย่อยห้ารายการที่เก็บองค์ประกอบข้อมูลเฉพาะสำหรับแต่ละฟีดข้อมูลห้ารายการ แต่ละระเบียน SuperType มีความสัมพันธ์แบบ 1: 1 กับระเบียนประเภทย่อยที่เหมาะสม

หากลูกค้าต้องการค้นหาแบบละเอียดพวกเขาต้องเลือกประเภท Super-Sub เช่น PropertyResidential

— Michael Riley - AKA Gunny
แหล่งที่มา

1

ในความเห็นของฉันความสัมพันธ์แบบ 1: 1 แสดงให้เห็นถึงการสืบทอดคลาสบน RDBMS มีตาราง A ที่มีแอ็ตทริบิวต์ร่วมกันเช่นสถานะคลาส partent แต่ละสถานะคลาสที่สืบทอดมาจะถูกแม็พบน RDBMS ด้วยตาราง B ที่มีความสัมพันธ์ 1: 1 กับตาราง A ซึ่งมีแอ็ตทริบิวต์พิเศษ ตาราง namend A บรรจุฟิลด์ "type" ที่แทนฟังก์ชัน "แคสติ้ง"

ลาก่อนมาริโอ

1

คุณสามารถสร้างตารางความสัมพันธ์แบบหนึ่งต่อหนึ่งหากมีประโยชน์ด้านประสิทธิภาพที่สำคัญ คุณสามารถใส่ฟิลด์ที่ไม่ค่อยได้ใช้ลงในตารางแยกกันได้

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

0

ความสัมพันธ์ 1: 1 ไม่สมเหตุสมผลถ้าคุณเข้าสู่ภาวะปกติเพราะอะไรก็ตามที่เป็น 1: 1 จะถูกเก็บไว้ในตารางเดียวกัน

ในโลกแห่งความเป็นจริงมันมักจะแตกต่างกัน คุณอาจต้องการแบ่งข้อมูลของคุณให้ตรงกับอินเทอร์เฟซแอปพลิเคชันของคุณ

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

ฉันไม่เห็นด้วยกับทฤษฎีตารางหนึ่ง มีบางครั้งที่ความสัมพันธ์ SuperType SubType แสดงออกได้ดีที่สุดด้วยความสัมพันธ์ 1: 1

— Michael Riley - AKA Gunny

1

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

— Tom H

0

อาจเป็นไปได้ถ้าคุณมีวัตถุที่พิมพ์ในฐานข้อมูลของคุณ

พูดในตาราง T1 คุณมีคอลัมน์ C1, C2, C3 ... ที่มีความสัมพันธ์แบบหนึ่งต่อหนึ่ง มันตกลงมันอยู่ในรูปแบบปกติ ตอนนี้พูดในตาราง T2 คุณมีคอลัมน์ C1, C2, C3, … (ชื่ออาจแตกต่างกัน แต่พูดว่าประเภทและบทบาทเหมือนกัน) โดยมีความสัมพันธ์แบบหนึ่งต่อหนึ่งเช่นกัน ไม่เป็นไรสำหรับ T2 ด้วยเหตุผลเดียวกับ T1

ในกรณีนี้ฉันเห็นว่าเหมาะสำหรับตาราง T3 ที่แยกกันถือ C1, C2, C3 ... และความสัมพันธ์แบบหนึ่งต่อหนึ่งจาก T1 ถึง T3 และจาก T2 ถึง T3 ฉันยิ่งเห็นว่าเหมาะสมถ้ามีตารางอื่นซึ่งมีอยู่หนึ่งต่อหลาย C1, C2, C3 ... พูดจากตาราง A ถึงหลายแถวในตาราง B จากนั้นแทน T3 คุณใช้ B และมี ความสัมพันธ์แบบหนึ่งต่อหนึ่งจาก T1 ถึง B เหมือนกันจาก T2 ถึง B และยังคงมีความสัมพันธ์แบบเดียวกันกับหลายความสัมพันธ์จาก A ถึง B

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

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

0

ไม่จำเป็นสำหรับการรักษาความปลอดภัย แต่มีวิธีที่ดีกว่าในการตรวจสอบความปลอดภัย ลองนึกภาพคุณสร้างกุญแจที่สามารถเปิดประตูเดียวเท่านั้น หากกุญแจสามารถเปิดประตูอื่นได้คุณควรส่งเสียงเตือน ในสาระสำคัญคุณสามารถมี "CitizenTable" และ "VotingTable" Citizen One โหวตให้กับ Candidate One ที่เก็บไว้ในตาราง Voting หากพลเมืองคนใดคนหนึ่งปรากฏในตารางการลงคะแนนอีกครั้งพวกเขาควรจะเป็นสัญญาณเตือน ขอคำแนะนำนี่เป็นความสัมพันธ์แบบหนึ่งต่อหนึ่งเพราะเราไม่ได้อ้างถึงเขตข้อมูลผู้สมัครเรากำลังอ้างถึงตารางการลงคะแนนและตารางพลเมือง

ตัวอย่าง:

 Citizen Table
 id = 1, citizen_name = "EvryBod"
 id = 2, citizen_name = "Lesly"
 id = 3, citizen_name = "Wasserman"

 Candidate Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"

จากนั้นหากเราเห็นตารางการลงคะแนนดังนี้:

 Voting Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"
 id = 4, citizen_id = 3, candidate_name = "Hill Arry"
 id = 5, citizen_id = 3, candidate_name = "Hill Arry"

เราสามารถพูดได้ว่าพลเมืองหมายเลข 3 เป็นกางเกงที่พูดพล่ามใส่ไฟซึ่งโกงเบอร์นีนี เป็นเพียงตัวอย่าง

— Lesly Revenge
แหล่งที่มา

0

เมื่อคุณจัดการกับฐานข้อมูลจากผลิตภัณฑ์ของบุคคลที่สามคุณอาจไม่ต้องการแก้ไขฐานข้อมูลเพื่อป้องกันการเชื่อมต่ออย่างแน่นหนา แต่คุณอาจมีข้อมูลที่สอดคล้องกับข้อมูล 1: 1

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

-4

ทุกแห่งมีองค์กรอิสระทั้งสองแห่งที่มีความสัมพันธ์แบบหนึ่งต่อหนึ่ง จะต้องมีตัวอย่างมากมาย:

คน <-> หมอฟัน(มันคือ 1: N ดังนั้นมันผิด!)

person <-> หมอ(ของ 1: N ดังนั้นมันผิดด้วย!)

person <-> คู่สมรส(1: 0 | 1, ดังนั้นมันผิดมาก!)

แก้ไข:ใช่สิ่งเหล่านี้เป็นตัวอย่างที่แย่มากโดยเฉพาะถ้าฉันมักจะมองหา 1: 1 ไม่ใช่ 0 หรือ 1 ทั้งสองข้าง ฉันเดาว่าสมองของฉันกำลังยิงผิด :-)

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

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

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

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

พอล

— พอลดับบลิวโฮเมอร์
แหล่งที่มา

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

ทำเครื่องหมายคุณสามารถทำตาราง "คู่รัก" ที่มีแถวเป็นคู่เสมอ แต่อย่างอื่นฉันเห็นด้วยกับคุณอืม ... โวยวาย : P

— JohannesH

ใช่ฉันเห็นด้วยกับมาร์คด้วย :-) (ฉันอนุญาตให้ยกเลิกคำตอบงี่เง่าของตัวเองได้หรือเปล่า)

— Paul W Homer

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

2

ฉันคิดเสมอว่าแม้แต่คนที่ฉลาดที่สุดในโลก (ใครก็ตามที่อาจเป็นในเวลานี้) ยังคงมีช่วงเวลาของความโง่เขลาของเต้านม มันเป็นคำสาปของมนุษย์ :-) ขณะที่คอมพิวเตอร์ของฉันมีช่วงเวลาที่ใกล้เคียงกับความฉลาด

— Paul W โฮเมอร์