ควรใช้ประเภทข้อมูล XML เมื่อใด

12

ฉันรับผิดชอบในการสร้างฐานข้อมูลในโครงการ เรามีสาขาที่ไม่ค่อยมีค่า (1 ในทุก ๆ 10,000 เรคคอร์ด) และฉันพยายามหาวิธีที่ดีที่สุดในการจัดเก็บในฐานข้อมูล

เท่าที่ฉันเห็นฉันมี 3 ตัวเลือก:

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

มีตัวเลือกอื่น ๆ ที่ฉันไม่ได้พิจารณาหรือไม่?

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

sql-server-2008 xml

— Matthew Steeples
แหล่งที่มา

1

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

— Marian

คุณพูดถึงฟิลด์พิเศษกี่สาขา และพวกเขามีเหตุผลที่จะเป็นส่วนหนึ่งของ Entity เดียวกันหรือไม่

— Andrew Bickerton

12

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

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

ฉันไม่สามารถจินตนาการโซลูชัน XML ที่ทำงานได้ดีในสถานการณ์นี้มันจะมีข้อมูลเมตาที่ซ้ำซ้อนจำนวนมากและจะช้าในการค้นหา

— ออกุสตุ
แหล่งที่มา

1

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

— Matthew Steeples

ฉันไม่แน่ใจว่าฉันอ่านสิ่งนี้ถูกต้องหรือไม่ แต่จากลิงก์ของคอลัมน์นี้มีการใช้ฐานข้อมูลว่าฉันกำลังมองหา 3 อยู่หรือไม่ blog.sqlauthority.com/2008/07/14/…

— Matthew Steeples

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

— ออกุส

5

คอลัมน์ nullable ไม่มีช่องว่างถ้าความยาวของตัวแปรใน SQL Server ความจริงของการเป็นโมฆะจะถูกเก็บไว้ในบิตแมปโมฆะ คุณสามารถสร้างดัชนีได้หากต้องการด้วยดัชนีที่กรองแล้วดังนั้นคุณจะไม่สนใจคอลัมน์ NULL
เพิ่มความซับซ้อนเมื่อคุณพิจารณาจุดที่ 1
อย่า ยากต่อการค้นหาแยกวิเคราะห์ ฯลฯ : คุณจะเสียใจในภายหลัง

นอกจากนี้ยังขึ้นอยู่กับขนาด: สิ่งนี้จะเป็นถ่าน (1,000) สำหรับสองสามพันล้านแถวหรือไม่ หรือจิ๋วสำหรับแถว 100k หากหลังพิจารณาความซับซ้อนที่เพิ่มขึ้นของจุดที่ 2: ไม่คุ้มค่า

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

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

— Matthew Steeples

1

@ Matthew ยอดแหลม: ฉันบอกว่าความยาวแปรผันนั้นไม่มีที่ว่างเลย และสำหรับการอ้างอิงsqlskills.com/BLOGS/PAUL/category/On-Disk-Structures.aspx#p41แถวสำหรับ 8 ไบต์เหล่านี้ได้อย่างไร

— GBN

ในขณะนี้เราอยู่ที่ 500,000 แถว แต่เรากำลังจะขยายตัว (หวังว่า) ในอัตราประมาณ 1 ล้านต่อวันทำงานทันทีที่เราอยู่อย่างเหมาะสม

— Matthew Steeples

3

ด้วย SQL Server 2008 คุณมีตัวเลือกเพิ่มเติมในการใช้คอลัมน์แบบกระจายซึ่งออกแบบมาโดยเฉพาะสำหรับสถานการณ์ที่คุณกล่าวถึง

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

ตรวจสอบบทความบล็อกต่อไปนี้เพื่อรับรายละเอียดเพิ่มเติม: http://www.sqlskills.com/BLOGS/PAUL/post/SQL-Server-2008-Sparse-columns-and-XML-COLUMN_SET.aspx

— เจฟฟ์
แหล่งที่มา

-4

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

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

3

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

— Andrew Bickerton