Saya mencari- cari database AdventureWorks hari ini dan saya perhatikan bahwa sejumlah tabel ( HumanResources.JobCandidatedan Sales.Individualmisalnya) memiliki kolom yang menyimpan data xml.
Apa yang saya ingin tahu adalah, apa keuntungan menyimpan pada dasarnya nilai data baris tabel database di kolom tabel lain? Tidakkah ini menyulitkan kueri informasi ini? Atau asumsi bahwa data tidak perlu ditanyakan dan hanya perlu disimpan?
Jawaban:
Karena tidak semua data perlu disimpan secara relasional dan menulis kode untuk memproses data yang telah Anda lewati sebagai XML untuk penyimpanan relasional memakan waktu (dan sangat sangat membosankan). Ini terutama benar ketika banyak data XML berasal dari sistem yang membuang respons generik besar.
Saya sering melihat situasi di mana pesan diterima dari sistem lain dan kami tidak peduli tentang 98% dari apa yang dikandungnya. Jadi kami menguraikannya untuk membagi 2% yang kami pedulikan, menyimpannya secara relasional dan kemudian menyimpan seluruh pesan jika kami membutuhkan 98% sisanya nanti.
Dan SQL Server memberi Anda beberapa alat OK-ish dan sintaks untuk bekerja dengan XML dalam T-SQL sehingga tidak seolah-olah itu benar-benar di luar jangkauan praktis untuk permintaan ad-hoc dengan cara yang mungkin terjadi jika Anda menyimpan, katakanlah, konten dari CSV.
Dan itu mengecualikan kemungkinan bahwa apa yang sebenarnya ingin Anda simpan adalah XML (misalnya untuk tujuan dukungan dan debug) ...
Jika format data volatil dan dapat berubah, Anda mungkin ingin menjadikannya sebagai XML dan dimasukkan ke dalam basis data dalam formulir ini sehingga menghindari perubahan skema basis data di masa mendatang.
Pada garis singgung yang sama, jika data dipasok oleh beberapa sistem eksternal dan dikonsumsi lagi, dan mereka tidak dapat memberi Anda format permanen, itulah yang akan Anda lakukan.
Tidakkah ini menyulitkan kueri informasi ini?
SQL Server dapat meminta bidang dan variabel XML. Tidak selalu sulit, tetapi lebih banyak pekerjaan, ya. Tapi bisa dilakukan.
Dalam pengalaman saya, data XML biasanya disimpan dan jarang ditanyakan, tetapi sering diekstraksi bila perlu, biasanya ketika beberapa sistem lain membutuhkan representasi XML dari beberapa data yang mungkin sulit atau tidak mungkin untuk dihasilkan secara on-the-fly dari data relasional. Data XML mungkin diisi sebelumnya oleh beberapa proses lainnya.
Jika Anda bisa membayangkan menyimpan data Anda dalam aliran biner dalam gumpalan, maka saya akan membayangkan Anda bisa membayangkan menyimpan data Anda dalam format xml dalam gumpalan.
Tentu saja, banyak hal yang tersisa dalam imajinasi sang imaginer.
Katakanlah, rekam medis elektronik misalnya:
Karena Anda kemungkinan besar akan menyimpan ASCII HL7 V2.x di bidang dalam database. Anda mungkin akan cenderung menyimpan HL7 V3.0 di bidang dalam database.
Jadi keuntungannya adalah kenyamanan.
Saat ini saya sedang mengerjakan proyek yang melakukan ini. Kami memiliki data yang perlu diproses berulang kali, disimpan secara relasional. Namun, pemrosesan dilakukan di Jawa, dan lebih mudah untuk bekerja dengan XML di sana. Jadi, kami melakukan satu kali melewati data relasional dan menyimpannya sebagai XML dalam sebuah tabel. Kemudian kita dapat memproses data di Jawa dengan satu permintaan yang tidak bergabung daripada mengambil data setiap waktu, dan memproses data yang sama berulang-ulang sesuai dengan isi hati kita. Itu jauh lebih sederhana dan lebih efisien.
Contoh yang baik untuk menyimpan XML adalah ketika Anda ingin mempertahankan status UI dalam database. Keadaan semua tampilan aplikasi adalah serial dan disimpan dalam database dan tidak perlu untuk meminta XML. Maksud saya UI, mengurutkan urutan tampilan, ukuran jendela, dll.
Seringkali Anda mendapatkan data campuran yang bersifat XML dan relasional. (Contoh bagus untuk ini adalah penyimpanan dokumen di mana setiap dokumen dapat memiliki bidang metadata seperti judul, tanggal pembuatan, pemilik dan sebagainya.)
Pada titik ini Anda harus memilih dari tiga opsi:
Opsi 3 mungkin yang paling bersih tetapi juga yang paling mahal dan paling sulit untuk diterapkan, ditambah Anda tidak perlu ingin transaksi terdistribusi dalam sistem yang tidak terlalu besar. Opsi 2 tidak terlalu bagus karena database XML asli biasanya sangat buruk dalam menangani data relasional (yang kemungkinan besar akan Anda gunakan dalam pencarian) dan teknologinya secara keseluruhan kurang matang daripada DB relasional.
Sehingga membuat Anda dengan opsi 1 tentu bukan solusi terbaik tapi mungkin yang paling buruk.
Dalam pengalaman saya, menggunakan XML dalam database akhirnya menjadi karena itulah sumber data menyimpannya, atau Anda menambahkannya ke database yang ada untuk memperluas fungsionalitas dengan cara yang tidak akan memerlukan banyak pemrograman database untuk mendukung .
Jika Anda akan sering mencari data baru, masuk akal untuk membagi XML menjadi bagian-bagian komponennya. Jika tidak, ini bisa menjadi cara yang berguna untuk menyimpan data yang jarang diubah.
Semoga ini bisa membantu, Jeff
Datastore berorientasi dokumen (alias NoSql) sangat populer hari ini:
http://en.wikipedia.org/wiki/Document-oriented_database
Tidak ada alasan Anda tidak dapat menggunakan skema berorientasi dokumen dalam database relasional. Anda mungkin tidak mendapatkan semua manfaat yang sama dibandingkan dengan sesuatu seperti Mongo, tetapi Anda juga tidak akan memiliki kekurangan.
Untuk waktu yang lama, jika Anda ingin menggunakan penyimpanan berorientasi dokumen, satu-satunya pilihan Anda adalah mendorong data terstruktur (seperti XML) ke dalam kolom besar. Database relasional telah menambahkan fitur seperti pengindeksan dan pencocokan untuk mendukung itu.
Berbeda dengan Mongo, di mana mereka hanya ada dalam database adalah dokumen. Tapi itu topik lain.
EDIT: ide inti berorientasi dokumen adalah: Anda menarik data keluar, memanipulasinya, dan mendorongnya kembali secara keseluruhan. Terkadang, seperti ketika Anda mengirimkan dokumen ke klien, Anda hanya ingin mengirim semuanya sebagai gumpalan dan membiarkan mereka menanganinya. Manfaat (dan kelemahannya) adalah fleksibilitas. Validasi dan kebenaran dokumen dilakukan di luar basis data.
EDIT EDIT: Kontras lain. Bayangkan menyimpan gambar JPG, atau dokumen Word dalam kolom database.
Apa keuntungan menyimpan pohon (XML) dalam daftar tupel (tabel basis data)?
Tidak ada alasan mengapa XML tidak bisa queriable dari DBMS Anda menggunakan misalnya XPath atau SPARQL.
Seperti yang saya lihat, mereka hanyalah dua struktur data yang berbeda. Dan tidak ada alasan mengapa mereka tidak boleh tertanam satu sama lain.
Anda dapat mencari alasan mengapa datatype JSON ditambahkan di PostgreSQL. Saya pikir banyak argumen yang sama berlaku. Kecuali dengan XML / XSD, bahkan lebih banyak validasi dimungkinkan.
Nah, XML (atau JSON) cukup bagus untuk menyimpan metadatas dengan hierarki. Apa saja alternatifnya? Tabel metadata dengan refid / key / value / depth mungkin? Agak rumit (tapi mungkin lebih baik untuk bertanya jika Anda perlu melakukannya). Menyimpan beberapa data xml tentang dokumen (satu baris dalam tabel dokumen) cukup nyaman ketika Anda ingin menyimpan beberapa info hierarkis tanpa harus bergantung pada tabel eksternal atau harus menambahkan 1 kolom per "jenis" info.
Saya akan mengatakan itu adalah praktik yang buruk karena Anda menyumbat penyimpanan yang efisien dengan tag tidak efisien yang tidak perlu ada di sana jika Anda berupaya untuk menguraikan informasi. XML memiliki overhead penyimpanan yang mengerikan dibandingkan dengan data yang dijelaskan, karena Anda memerlukan satu tag untuk setiap kolom untuk setiap baris. Sebagai perbandingan, data yang diuraikan dan disimpan dalam format relasional memiliki nama kolomnya yang disimpan SEKALI. Untuk selusin baris pada dev. kotak, masalah besar, tetapi saya telah melihat pengembang membuat asumsi ini scalable ke jutaan baris. Ini dapat mewakili 100-an dari GB overhead untuk beberapa lusin GB data, yang menciptakan tantangan operasional. Anda pada dasarnya melepaskan tanggung jawab dari diri sendiri dan mendorong orang-orang yang harus mendukung omong kosong yang Anda tulis.
Jadi, mengapa tidak menyimpannya JAUH dari data operasional, di basis datanya sendiri? Atau seperti yang dimaksudkan - dalam file datar? Mungkin tidak akan pernah dilihat lagi, jadi mengapa tidak menghapusnya dari memukul kinerja sistem operasional? Ingat bahwa XML HANYA di sana untuk memberikan deskripsi skema data yang tidak akan terlihat karena perbedaan protokol penyimpanan antara sistem. Itulah intinya, tidak ada yang pintar tentang hal itu. Menyimpan 10x jumlah overhead untuk jumlah data tertentu hanya mengatakan Anda adalah seorang pengembang yang ceroboh yang tidak memikirkan hal-hal dan tidak dapat memproses data yang Anda konsumsi menjadi format yang masuk akal, efisien, cepat untuk query. Berhenti mendorong upaya Anda ke dukungan operasional, dan BERPIKIR tentang bagaimana Anda dapat menangani data dengan lebih baik setelah Anda Saya sudah menerimanya akan menjadi panggilan saya. Tidak ada pertahanan untuk menyimpan data sebagai XML setelah diterima, karena sudah melayani tujuannya.