วันนี้ฉันได้พูดคุยกับฐานข้อมูล AdventureWorks และฉันสังเกตเห็นว่ามีตารางจำนวนหนึ่ง ( HumanResources.JobCandidateและ Sales.Individualตัวอย่าง) มีคอลัมน์ที่เก็บข้อมูล xml
สิ่งที่ฉันจะรู้ก็คือข้อดีของการจัดเก็บข้อมูลมูลค่าของแถวฐานข้อมูลในคอลัมน์ของตารางอื่นคืออะไร สิ่งนี้ทำให้การสืบค้นข้อมูลนี้ยากหรือไม่ หรือสมมติฐานที่ว่าข้อมูลไม่จำเป็นต้องถูกสอบถามและเพียงแค่ต้องถูกจัดเก็บ?
คำตอบ:
เพราะไม่ใช่ว่าข้อมูลทั้งหมดจะต้องถูกจัดเก็บอย่างสัมพันธ์และการเขียนรหัสเพื่อประมวลผลข้อมูลที่คุณได้รับผ่านเนื่องจาก XML สำหรับการจัดเก็บเชิงสัมพันธ์นั้นใช้เวลานาน (และน่าเบื่อมาก) นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งเมื่อข้อมูล XML จำนวนมากมาจากระบบซึ่งทำให้เกิดการตอบกลับทั่วไปขนาดใหญ่
ฉันเคยเห็นสถานการณ์ที่ได้รับข้อความจากระบบอื่นบ่อยครั้งและเราไม่สนใจประมาณ 98% ของสิ่งที่มีอยู่ ดังนั้นเราจึงแยกวิเคราะห์เพื่อแยก 2% ที่เราสนใจเก็บที่สัมพันธ์แล้วเก็บข้อความทั้งหมดในกรณีที่เราต้องการส่วนที่เหลืออีก 98% ในภายหลัง
และ SQL Server ให้คุณมีเครื่องมือและไวยากรณ์ OK-ish สำหรับการทำงานกับ XML ใน T-SQL ดังนั้นมันจึงไม่เหมือนกับการเข้าถึงคำสั่ง ad-hoc ในทางที่เป็นไปได้จริงหากคุณเก็บไว้พูดเนื้อหา ของ CSV
และนั่นไม่รวมถึงความเป็นไปได้ที่สิ่งที่คุณต้องการจัดเก็บจริงคือ XML (เช่นเพื่อการสนับสนุนและการดีบัก) ...
หากรูปแบบข้อมูลมีความผันผวนและอาจมีการเปลี่ยนแปลงที่เป็นไปได้คุณอาจต้องการรวมเข้าด้วยกันเป็น XML และใส่ลงในฐานข้อมูลในรูปแบบนี้จึงหลีกเลี่ยงการเปลี่ยนสคีมาฐานข้อมูลในอนาคต
ในสัมผัสเดียวกันหากข้อมูลถูกจัดทำโดยระบบภายนอกบางระบบและใช้งานอีกครั้งและพวกเขาไม่สามารถให้รูปแบบถาวรกับคุณได้นั่นคือสิ่งที่คุณจะทำ
สิ่งนี้ทำให้การสืบค้นข้อมูลนี้ยากหรือไม่
SQL Server สามารถสืบค้นฟิลด์ XML และตัวแปรได้ ไม่จำเป็นต้องยาก แต่ก็ใช้ได้มากกว่าใช่ แต่ทำได้
จากประสบการณ์ของฉันข้อมูล XML มักถูกเก็บไว้และสอบถามบ่อยครั้ง แต่แยกออกมาเมื่อจำเป็นโดยปกติเมื่อระบบอื่นต้องการการแสดง XML ของข้อมูลบางอย่างที่อาจเป็นเรื่องยากหรือเป็นไปไม่ได้ที่จะสร้างข้อมูลแบบทันที ข้อมูล XML อาจถูกเติมไว้ล่วงหน้าโดยกระบวนการอื่น
หากคุณสามารถนึกภาพการจัดเก็บข้อมูลของคุณในสตรีมแบบไบนารีในหยดแล้วฉันคิดว่าคุณสามารถจินตนาการการจัดเก็บข้อมูลของคุณในรูปแบบ xml ในหยด
แน่นอนว่ามีหลายสิ่งที่ดีที่สุดในจินตนาการของนักวาดภาพ
กล่าวว่าเวชระเบียนอิเล็กทรอนิกส์เช่น:
เนื่องจากคุณมักจะเก็บ ASCII HL7 V2.x ในเขตข้อมูลในฐานข้อมูล คุณอาจจะเหมาะที่จะเก็บ HL7 V3.0 ในฟิลด์ในฐานข้อมูล
ดังนั้นข้อดีคือความสะดวกสบาย
ฉันกำลังทำงานในโครงการที่ทำสิ่งนี้ เรามีข้อมูลที่ต้องประมวลผลหลายครั้งจัดเก็บตามความสัมพันธ์ อย่างไรก็ตามการประมวลผลทำใน Java และทำงานกับ XML ได้ง่ายขึ้น ดังนั้นเราทำการส่งผ่านข้อมูลเชิงสัมพันธ์แบบครั้งเดียวและเก็บไว้เป็น XML ในตาราง จากนั้นเราสามารถประมวลผลข้อมูลนั้นใน Java ด้วยแบบสอบถามที่ไม่ได้เข้าร่วมหนึ่งรายการแทนที่จะดึงข้อมูลทุกครั้งและประมวลผลข้อมูลเดียวกันซ้ำแล้วซ้ำอีกในเนื้อหาหัวใจของเรา มันง่ายกว่าและมีประสิทธิภาพมากกว่า
ตัวอย่างที่ดีของการจัดเก็บ XML คือเมื่อคุณต้องการคงสถานะ UI ในฐานข้อมูล สถานะของมุมมองแอ็พพลิเคชันทั้งหมดถูกทำให้เป็นอนุกรมและเก็บไว้ในฐานข้อมูลและไม่จำเป็นต้องเคียวรี XML ตามสถานะ UI ฉันหมายถึงเรียงลำดับการดูขนาดของหน้าต่างเป็นต้น
บ่อยครั้งที่คุณได้รับข้อมูลแบบผสมที่เป็นทั้ง XML และความสัมพันธ์ (ตัวอย่างที่ดีของเรื่องนี้คือที่เก็บเอกสารซึ่งแต่ละเอกสารสามารถมีเขตข้อมูลเมทาดาทาเช่นชื่อเรื่องวันที่สร้างเจ้าของและอื่น ๆ )
ณ จุดนี้คุณต้องเลือกจากสามตัวเลือก:
ตัวเลือกที่ 3 น่าจะสะอาดที่สุด แต่ก็แพงที่สุดและยากที่สุดที่จะนำมาใช้รวมถึงคุณไม่จำเป็นต้องทำธุรกรรมแบบกระจายในระบบที่ไม่ใหญ่มาก ตัวเลือกที่ 2 นั้นไม่ค่อยดีนักเนื่องจากฐานข้อมูล XML ดั้งเดิมนั้นแย่มากในการจัดการข้อมูลเชิงสัมพันธ์ (ซึ่งคุณมีแนวโน้มที่จะใช้ในการค้นหา) และเทคโนโลยีโดยรวมนั้นมีอายุน้อยกว่า DB เชิงสัมพันธ์
ดังนั้นนั่นจะทำให้คุณมีตัวเลือกที่ 1 อย่างแน่นอนไม่ใช่ทางออกที่ดีที่สุด แต่อาจแย่ที่สุด
จากประสบการณ์ของฉันการใช้ XML ในฐานข้อมูลกลายเป็นเพราะนั่นคือที่มาของข้อมูลที่เก็บไว้หรือคุณกำลังเพิ่มลงในฐานข้อมูลที่มีอยู่เพื่อขยายการทำงานในแบบที่ไม่ต้องใช้การเขียนโปรแกรมฐานข้อมูลจำนวนมากเพื่อสนับสนุน .
หากคุณกำลังจะค้นหาข้อมูลใหม่บ่อยครั้งมันอาจจะเหมาะสมที่จะแยก XML ออกเป็นส่วนต่างๆแทน หากไม่เป็นเช่นนั้นอาจเป็นวิธีที่มีประโยชน์ในการบันทึกข้อมูลที่เปลี่ยนแปลงไม่บ่อย
หวังว่านี่จะช่วยเจฟ
วันนี้มุ่งเน้นไปที่เอกสาร - เอกสาร (aka NoSql):
http://en.wikipedia.org/wiki/Document-oriented_database
ไม่มีเหตุผลที่คุณไม่สามารถใช้รูปแบบเอกสารที่มุ่งเน้นในฐานข้อมูลเชิงสัมพันธ์ คุณอาจไม่ได้รับผลประโยชน์แบบเดียวกันทั้งหมดเมื่อเทียบกับบางอย่างเช่น Mongo แต่คุณจะไม่มีข้อเสียเช่นกัน
เป็นเวลานานหากคุณต้องการใช้ที่เก็บเอกสารเชิงเลือกเดียวของคุณคือการผลักข้อมูลโครงสร้าง (เช่น XML) ลงในคอลัมน์ขนาดใหญ่ ฐานข้อมูลเชิงสัมพันธ์ได้เพิ่มคุณสมบัติเช่นการจัดทำดัชนีและการจับคู่เพื่อรองรับ
ตรงกันข้ามกับ Mongo ที่มีเพียงสิ่งเดียวในฐานข้อมูลคือเอกสาร แต่นั่นเป็นหัวข้ออื่น
แก้ไข: แนวคิดหลักของการมุ่งเน้นเอกสารคือ: คุณดึงข้อมูลออกจัดการกับมันและดันกลับเข้าไปใหม่ทั้งหมด บางครั้งเช่นเมื่อคุณส่งเอกสารไปยังลูกค้าคุณเพียงแค่ต้องการส่งสิ่งทั้งหมดเป็นหยดและให้พวกเขาจัดการกับมัน ประโยชน์ (และข้อเสียเปรียบ) คือความยืดหยุ่น การตรวจสอบและความถูกต้องของเอกสารนั้นกระทำนอกฐานข้อมูล
แก้ไขแก้ไข: ความคมชัดอื่น ลองนึกภาพการบันทึกภาพ JPG หรือเอกสาร Word ในคอลัมน์ฐานข้อมูล
อะไรคือข้อดีของการจัดเก็บแผนภูมิ (XML) ในรายการของสิ่งอันดับ (ตารางฐานข้อมูล)?
ไม่มีเหตุผลใดที่ XML ไม่น่าจะสอบถามจาก DBMS ของคุณโดยใช้เช่น XPath หรือ SPARQL
อย่างที่ฉันเห็นมันเป็นเพียงโครงสร้างข้อมูลสองแบบที่แตกต่างกัน และไม่มีเหตุผลว่าทำไมพวกเขาไม่ควรฝังตัวเข้าหากัน
คุณสามารถค้นหาสาเหตุของการเพิ่มประเภทข้อมูล JSON ใน PostgreSQL ฉันคิดว่ามีการโต้แย้งแบบเดียวกันหลายข้อ นอกจากนั้นด้วย XML / XSD คุณสามารถตรวจสอบได้มากขึ้น
ดี XML (หรือ JSON) ค่อนข้างดีในการจัดเก็บเมตาดาต้าที่มีลำดับชั้น ทางเลือกคืออะไร? ตารางเมทาดาทาที่มี refid / key / value / depth อาจจะ? มันค่อนข้างยุ่งยาก (แต่อาจดีกว่าสำหรับการสืบค้นหากคุณจำเป็นต้องทำ) การจัดเก็บข้อมูล xml บางอย่างเกี่ยวกับเอกสาร (แถวในตารางเอกสาร) ค่อนข้างสะดวกเมื่อคุณต้องการจัดเก็บข้อมูลข่าวสารแบบลำดับชั้นโดยไม่ต้องพึ่งพาตารางภายนอกหรือต้องเพิ่มคอลัมน์ 1 คอลัมน์ต่อ "ประเภท" ของข่าวสาร
ฉันว่ามันเป็นวิธีปฏิบัติที่ไม่ดีเพราะคุณกำลังอุดตันการจัดเก็บข้อมูลที่มีประสิทธิภาพด้วยแท็กที่ไม่มีประสิทธิภาพซึ่งไม่จำเป็นต้องอยู่ที่นั่นหากคุณพยายามแยกวิเคราะห์ข้อมูล XML มีโอเวอร์เฮดที่จัดเก็บข้อมูลที่น่าประทับใจเมื่อเปรียบเทียบกับข้อมูลที่อธิบายเนื่องจากคุณต้องการหนึ่งแท็กสำหรับแต่ละคอลัมน์สำหรับแต่ละแถว โดยการเปรียบเทียบข้อมูลแยกวิเคราะห์และจัดเก็บในรูปแบบเชิงสัมพันธ์มีชื่อคอลัมน์ของมันถูกจัดเก็บครั้งเดียว สำหรับแถวโหลบน dev กล่องเรื่องใหญ่ แต่ฉันเคยเห็นนักพัฒนาตั้งสมมติฐานว่ามันสามารถปรับขนาดได้เป็นล้านแถว สิ่งนี้สามารถแสดงถึงค่าใช้จ่าย 100 GB สำหรับข้อมูลสองสาม GB ซึ่งสร้างความท้าทายในการดำเนินงาน โดยทั่วไปคุณสละความรับผิดชอบจากตัวเองและผลักดันคนที่ต้องสนับสนุนอึที่คุณเขียน
ดังนั้นทำไมไม่เก็บออกจากข้อมูลการดำเนินงานในฐานข้อมูลของตัวเอง? หรือตามที่ตั้งใจไว้ - ในไฟล์แบน? มันอาจจะไม่ถูกมองอีกครั้งดังนั้นทำไมไม่ลบออกจากการกดปุ่มประสิทธิภาพของระบบปฏิบัติการ? โปรดจำไว้ว่า XML นั้นมีไว้เพื่อให้คำอธิบายสคีมาของข้อมูลเท่านั้นมิฉะนั้นจะไม่ปรากฏเนื่องจากความแตกต่างของโปรโตคอลการจัดเก็บระหว่างระบบ นั่นคือประเด็นทั้งหมดไม่มีอะไรที่ฉลาดเกี่ยวกับเรื่องนี้ การจัดเก็บค่าโสหุ้ยจำนวน 10 เท่าสำหรับข้อมูลที่ระบุเพียงแค่บอกว่าคุณเป็นนักพัฒนาที่เลอะเทอะซึ่งไม่ได้คิดอะไรหลายอย่างและไม่สามารถประมวลผลข้อมูลที่คุณบริโภคในรูปแบบที่สมเหตุสมผลและรวดเร็ว หยุดความพยายามของคุณสู่การสนับสนุนการปฏิบัติงานและคิดว่าคุณจะจัดการกับข้อมูลได้ดีขึ้นอย่างไรหลังจากคุณ ได้รับมันจะเป็นสายของฉัน ไม่มีการป้องกันสำหรับการจัดเก็บข้อมูลเป็น XML หลังจากได้รับเนื่องจากมีจุดประสงค์