การจัดหาเหตุการณ์ SQL เติมตารางหลักและตารางลูก

ติดตามผลจากคำถาม CQRS Read การออกแบบโมเดลเมื่อมีการจัดหากิจกรรมโดยมีความสัมพันธ์ระหว่างพ่อแม่-ลูก-หลาน...:

เราใช้การจัดหากิจกรรมด้วย SQL Server 2016 ที่ตัวอย่าง: บริษัทเฟอร์นิเจอร์
(1) เรามีตารางหลักและรอง พูด FurnitureDescriptionTable (ตารางหลัก- คำอธิบายรายการเฟอร์นิเจอร์ทั้งหมด) และ FurnitureOrders (รายการย่อย - คำสั่งซื้อจากลูกค้าหลายราย หมายถึงตาราง FurnitureDescription) คอลัมน์รวมระหว่างสิ่งเหล่านี้ควรเป็น Guid หรือ Integer Identity ใน SQL หรือไม่

(2) ถ้า Guid ใครเป็นผู้สร้าง Guid, API หรือ SQL มีเหตุผลอะไรไหม?




คำตอบ (1)


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

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

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

person Alexey Zimarev    schedule 18.09.2017
comment
ฉันคิดว่าฉันเรียบเรียงคำถามมากเกินไป ฉันวางคำถามใหม่ไว้ที่นี่ตามที่แนะนำโดย stackoverflow คราวนี้เรามีความสัมพันธ์มากกว่า 100 รายการในที่จัดเก็บงานเขียน stackoverflow.com/questions/46289332/ - person ; 19.09.2017