มันไม่สมเหตุสมผลที่จะรวมความสัมพันธ์แบบหนึ่งต่อหนึ่งหรือไม่?

หากเรามีตาราง A ที่มีความสัมพันธ์แบบหนึ่งต่อหนึ่งกับตาราง B มันทำให้รู้สึกถึงความแตกต่างหรือไม่? หรือไม่เคยเจ็บที่จะรวมมันไว้ในตารางเดียว? ทำอย่างใดอย่างหนึ่งในสถานการณ์เหล่านี้ (สองตารางเทียบกับตารางที่รวมกันหนึ่งตาราง) ส่งผลต่อสิ่งใด ๆ ที่เกี่ยวกับรูปแบบปกติ (1NF, 2NF, 3NF ฯลฯ )

ใช่มีหลายสาเหตุที่ทำให้การออกแบบดีกว่านี้

คุณอาจมีความสัมพันธ์ที่สืบทอด / นามสกุลเช่นคุณอาจมีUserตารางแล้วAdministratorตารางที่มีเขตข้อมูลเพิ่มเติม ตารางทั้งสองอาจมีคีย์หลักของ ID ผู้ใช้ (และดังนั้นจึงมีความสัมพันธ์แบบ 1: 1) แต่ผู้ใช้บางรายอาจไม่มีระเบียนในAdministratorตาราง คุณจะต้องมีสิ่งที่คล้ายกันถ้าคุณสนับสนุนเวิร์กโฟลว์เช่นScheduledTaskโต๊ะและCompletedTaskโต๊ะ

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

คุณอาจต้องการสิทธิ์ต่าง ๆ ในตารางเช่นUserและUserCredentials

คุณอาจต้องการกลยุทธ์การสำรองข้อมูลที่แตกต่างกันและดังนั้นจึงวางสองตารางลงในพาร์ติชันที่แตกต่างกันเช่นTransactionและTransactionArchive

คุณอาจต้องการคอลัมน์มากกว่าที่จะได้รับการสนับสนุนในตารางเดียวเช่นหากมีคอลัมน์ข้อความขนาดใหญ่จำนวนมากที่คุณต้องสามารถจัดทำดัชนีและแพลตฟอร์ม DB ของคุณถูก จำกัด ไว้ที่หน้าข้อมูล 4K หรือ whathaveyou

การเพิ่มคำตอบที่ยอดเยี่ยมโดย @ john-wu อีกเหตุผลหนึ่งคือเมื่อคุณมีคอลัมน์ประเภท BLOB เหมือนภาพ

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

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

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

ตัวอย่างเช่น:

type Transaction(The_Type: PaymentType := Cash) is record

    Amount: Integer;

    case The_Type is
        when Cash =>
            Discount: boolean;
        when Check =>
            CheckNumber: Positive;
        when Credit =>
            CardNumber: String(1..5);
            Expiration: String(1..5);
    end case;
end record;

ในการสร้างแบบจำลองทางธุรกิจเอนทิตี A และ B สองรายการที่แยกกันอย่างมีเหตุผลจากมุมมองทางธุรกิจโดยทั่วไปจะแมปกับตารางที่แตกต่างกัน

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

จากประสบการณ์ของฉันเมื่อสร้างโมเดลธุรกิจหรือ OO data การแยกแบบลอจิคัลนี้เป็นเรื่องปกติสำหรับความสัมพันธ์แบบ 1: 1 มากกว่าเหตุผล "ทางกายภาพ" เช่นประสิทธิภาพความปลอดภัยส่วนบุคคลหรือการแบ่งพาร์ติชัน