ฉันควรใช้ชนิดข้อมูล XML ใน SQL Server เมื่อใด

ฉันควรใช้ชนิดข้อมูล XML ใน Microsoft SQL Server เมื่อใด

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

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

กรณีศึกษาทางธุรกิจที่ดีที่สุดที่ฉันเห็นอาจอยู่ในการบันทึกข้อความข้อมูลที่อิงกับ XML ที่คุณได้รับซึ่งคุณอาจต้องการมองดูโครงสร้างและข้อมูลของพวกเขา แต่ต้องการรักษาความสมบูรณ์ของข้อความต้นฉบับด้วยเหตุผลทางธุรกิจหรือทางกฎหมาย โอเวอร์เฮดอาจยอดเยี่ยมเกินกว่าที่จะแปล XML เป็นโครงสร้างตาราง แต่การใช้ความสามารถ XML ใน SQL Server อาจลดค่าใช้จ่ายในการตรวจสอบข้อมูลที่เพียงพอที่จะรับประกันการใช้งาน

อาจมีเหตุผลอื่นอีกหลายสิบข้อว่าทำไมคุณถึงต้องการใช้มัน แต่ฉันคิดว่าคุณควรพิจารณาเส้นทางอื่น ๆ เพื่อความสุขก่อนที่จะเข้าร่วมกับ XML ใน SQL Server เว้นแต่คุณจะมีเหตุผลทางธุรกิจที่เฉพาะเจาะจงสำหรับการทำเช่นนั้น ใช้ varchar (สูงสุด) หรือฟิลด์ข้อความหากเหมาะสมกว่า

แค่ความเห็นของฉันแน่นอน :)

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

• การจัดเก็บ / จัดเก็บการตอบกลับ XML ที่สร้างโดยแอปพลิเคชันอื่น
  • ตัวอย่างเช่นเราใช้ Application Integration Framework (AIF) สำหรับการสื่อสารระหว่างแอปพลิเคชัน Silverlight ที่กำหนดเองและ Dynamics AX เราจัดเก็บข้อความทั้งขาเข้าและขาออกในฐานข้อมูลเพื่อช่วยในการแก้ไขปัญหาการสื่อสารระหว่างแอปพลิเคชันเหล่านั้น
  • เนื่องจากประเภทฟิลด์เป็น XML แทนที่จะเป็นประเภทสตริงทั่วไป (เช่น VARCHAR) เราจึงสามารถใช้ XQuery เพื่อค้นหาข้อความที่ตรงกับเกณฑ์เฉพาะบางประการโดยเฉพาะ นี่จะยากกว่านี้ด้วยการจับคู่สตริงอย่างง่าย
• การแคช / ข้อความตอบกลับที่สงบ
  • อัปเดตฟิลด์ XML ด้วยทริกเกอร์หรือรหัสแอปพลิเคชันซึ่งจะเลียนแบบคอลัมน์ที่คำนวณ
  • แทนที่จะสร้างการตอบสนอง XML ใหม่ให้กับแอปพลิเคชันการโทรอย่างต่อเนื่องโดยคุณจะได้รับค่าโสหุ้ยเฉพาะเมื่อแถวนั้นมีการเพิ่มขึ้นมากกว่าทุกครั้งที่โทร
  • วิธีนี้จะทำงานได้ดีที่สุดเมื่อ SELECT เลือกบ่อยกว่า UPDATEs / INSERT มากซึ่งมีแนวโน้มที่จะเป็นจริงสำหรับแอปพลิเคชัน
• การจัดเก็บค่าหลายค่าในฟิลด์เดียว
  • หนึ่งในแนวปฏิบัติที่ฉันได้เห็นคือการใช้ชนิดข้อมูล XML เพื่อเก็บค่าในฟิลด์เดียว
  • ข้อดีอย่างหนึ่งคือคุณไม่จำเป็นต้องออกแบบชุดตารางเพิ่มเติมสำหรับที่เก็บคีย์ / ค่าแบบง่าย
  • ข้อเสียของสิ่งนี้คือข้อมูลไม่ได้ถูกทำให้เป็นมาตรฐานอย่างสมบูรณ์ทำให้การสืบค้นไม่ชัดเจน
  • อย่างไรก็ตามดังที่ได้กล่าวไว้ข้างต้นคุณสามารถใช้ XQuery บนฟิลด์ XML นั้นเพื่อเลือกแถวที่ตรงกับเกณฑ์การระบุดังนั้นบางส่วนจึงแสดงผลกระทบของการไม่ทำให้เป็นมาตรฐานอย่างสมบูรณ์

ทั้งหมดที่กล่าวว่า 99% ของเวลาฉันไม่จำเป็นต้องมีฟิลด์ XML อย่างแน่นอนเมื่อออกแบบสคีมา

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

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

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

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

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

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

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