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

มีสองตาราง: และDeal DealCategoriesดีลหนึ่งสามารถมีได้หลายประเภทดีล

ดังนั้นวิธีที่เหมาะสมควรทำตารางที่DealCategoriesมีโครงสร้างดังนี้

DealCategoryId (PK)
DealId (FK)
DealCategoryId (FK)

อย่างไรก็ตามทีมงานภายนอกของเราเก็บหลายหมวดหมู่ไว้ใน Dealตารางด้วยวิธีนี้:

DealId (PK)
DealCategory -- In here they store multiple deal ids separated by commas like this: 18,25,32.

ฉันรู้สึกว่าสิ่งที่พวกเขาทำผิด แต่ฉันไม่รู้วิธีอธิบายอย่างชัดเจนว่าทำไมสิ่งนี้ไม่ถูกต้อง

ฉันจะอธิบายให้พวกเขาฟังได้อย่างไรว่าสิ่งนี้ผิด หรือบางทีฉันเป็นคนที่ผิดและเป็นที่ยอมรับ?

ใช่มันเป็นความคิดที่แย่มาก

แทนที่จะไป:

SELECT Deal.Name, DealCategory.Name
FROM Deal
  INNER JOIN
     DealCategories ON Deal.DealID = DealCategories.DealID
  INNER JOIN
     DealCategory ON DealCategories.DealCategoryID = DealCategory.DealCategoryID
WHERE Deal.DealID = 1234

ตอนนี้คุณต้องไป:

SELECT Deal.ID, Deal.Name, DealCategories
FROM Deal
WHERE Deal.DealID = 1234

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

SELECT DealCategory.Name
FROM DealCategory
WHERE DealCategory.DealCategoryID IN (<<that list from before>>)

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

SQL Antipatterns (Karwin, 2010) อุทิศทั้งบทให้กับ antipattern นี้ (ซึ่งเขาเรียกว่า 'Jaywalking') หน้า 15-23 นอกจากนี้ผู้เขียนได้โพสต์ในคำถามที่คล้ายกันมากกว่าที่ SO ประเด็นสำคัญที่เขาบันทึกไว้ (ตามที่ใช้กับตัวอย่างนี้) คือ:

• การสืบค้นข้อตกลงทั้งหมดในหมวดหมู่ที่เฉพาะเจาะจงนั้นค่อนข้างซับซ้อน (วิธีที่ง่ายที่สุดในการแก้ปัญหานั้นคือนิพจน์ทั่วไป แต่นิพจน์ทั่วไปเป็นปัญหาในตัวของมันเอง)
• คุณไม่สามารถบังคับใช้ Referential Integrity ได้หากไม่มีความสัมพันธ์กับ Foreign Key หากคุณลบ DealCategory nr # 26 ในรหัสแอปพลิเคชันของคุณคุณต้องทำตามข้อตกลงแต่ละข้อเพื่อค้นหาการอ้างอิงถึงหมวดหมู่ # 26 และลบออก นี่คือสิ่งที่ควรจัดการที่ชั้นข้อมูลและการจัดการกับมันในแอปพลิเคชันของคุณเป็นสิ่งที่เลวร้ายมากเป็นสิ่งที่เลวร้ายมาก
• คำสั่งรวม ( COUNT, SUMฯลฯ ) อีกครั้งแตกต่างจาก 'ซับซ้อน' ถึง 'ไปไม่ได้เกือบ' ถามนักพัฒนาของคุณว่าพวกเขาจะทำให้คุณได้รับรายชื่อหมวดหมู่ทั้งหมดที่มีจำนวนข้อเสนอในหมวดหมู่นั้น ๆ อย่างไร ด้วยการออกแบบที่เหมาะสมนั่นคือ SQL สี่บรรทัด
• การอัปเดตกลายเป็นเรื่องยากมากขึ้น (เช่นคุณมีดีลอยู่ในห้าหมวดหมู่ แต่คุณต้องการลบสองรายการและเพิ่มอีกสามหมวดหมู่) นั่นคือ SQL สามบรรทัดที่มีการออกแบบที่เหมาะสม
• ในที่สุดคุณจะพบVARCHARข้อจำกัดความยาวของรายการ แม้ว่าคุณจะมีรายการที่คั่นด้วยเครื่องหมายจุลภาคที่มีมากกว่า 4,000 ตัวอักษร แต่โอกาสในการแยกมอนสเตอร์นั้นก็จะช้าเหมือนนรกอยู่ดี
• การดึงรายการออกจากฐานข้อมูลแยกออกแล้วกลับไปที่ฐานข้อมูลสำหรับแบบสอบถามอื่นช้ากว่าภายในหนึ่งแบบสอบถาม

TLDR: มันเป็นข้อบกพร่องพื้นฐานการออกแบบมันไม่ได้ปรับขนาดได้ดีมันนำเสนอความซับซ้อนเพิ่มเติมแม้กระทั่งการสืบค้นที่ง่ายที่สุด

อย่างไรก็ตามทีมงานภายนอกของเราเก็บหลายหมวดหมู่ไว้ในตารางดีลด้วยวิธีนี้:

DealId (PK) DealCategory - ในที่นี่พวกเขาเก็บรหัสการจัดการหลายรายการคั่นด้วยเครื่องหมายจุลภาคเช่นนี้: 18,25,32

ที่จริงการออกแบบที่ดีถ้าคุณเพียงต้องแบบสอบถามสำหรับประเภทการจัดการที่ได้รับ

แต่มันแย่มากถ้าคุณต้องการทราบข้อเสนอทั้งหมดในหมวดหมู่ที่กำหนด

และยังทำให้ยากและมีข้อผิดพลาดเกิดขึ้นได้ง่ายเช่นการอัปเดตการนับการเข้าร่วม ฯลฯ

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

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

ค่าหลายค่าในคอลัมน์ขัดกับรูปแบบปกติที่ 1

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

การใช้งานที่ถูกต้องจะเป็นตารางทางแยกเช่น "DealDealCategories" พร้อมกับ DealId และ DealCategoryId

การใช้งานลำดับชั้นไม่ดี?

นอกจากนี้ FK ใน DealCategories ไปยัง DealCategory อื่นดูเหมือนว่าการใช้งานที่ไม่ดีของลำดับชั้น / ทรีของ DealCategories การทำงานกับต้นไม้ผ่านความสัมพันธ์ของผู้ปกครอง (เรียกว่ารายการ adjacency) เป็นความเจ็บปวด!

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