Menggunakan XML sebagai penyimpanan data [ditutup]

Saya sedang berpikir tentang format XML dan kutipan berikut:

“XML bukan database. Itu tidak pernah dimaksudkan sebagai database. Tidak akan pernah menjadi database. Database relasional adalah teknologi yang terbukti dengan lebih dari 20 tahun pengalaman implementasi. Mereka adalah produk padat, stabil, bermanfaat. Mereka tidak akan pergi. XML adalah teknologi yang sangat berguna untuk memindahkan data antara basis data yang berbeda atau antara basis data dan program lainnya. Namun, itu sendiri bukan database. Jangan menggunakannya seperti satu. "- XML efektif: 50 Cara spesifik untuk Meningkatkan XML Anda oleh Elliotte Rusty Harold (halaman 230, Bagian 4, Item 41, paragraf ke-2)

Ini tampaknya benar-benar menekankan bahwa XML tidak boleh digunakan untuk penyimpanan data dan seharusnya hanya digunakan untuk program untuk program interoperabilitas.

Secara pribadi, saya tidak setuju dan app.configfile .NET yang digunakan untuk menyimpan pengaturan program adalah contoh penyimpanan data dalam file XML. Namun untuk database daripada konfigurasi dll XML tidak boleh digunakan.

Untuk mengembangkan poin saya, saya akan menggunakan dua contoh:
A) Data tentang pelanggan dengan bidang yang semuanya pada satu tingkat yaitu ada sejumlah bidang semua yang berkaitan dengan satu pelanggan tanpa anak-anak
B) Data tentang konfigurasi aplikasi di mana bidang bersarang dan properti sangat masuk akal

Jadi pertanyaan saya adalah, Apakah ini masih pernyataan yang valid dan apakah sekarang dapat diterima untuk menyimpan data menggunakan XML?

EDIT: Saya telah mengirim email ke penulis kutipan itu untuk meminta masukan / konteks ekstra.

Kutipan ini bukan tentang menggunakan XML sebagai format penyimpanan secara umum (yang baik-baik saja, tergantung pada persyaratan), tetapi untuk penyimpanan tipe- database .

Ketika orang berbicara tentang database, mereka biasanya berarti sistem penyimpanan yang menyimpan data dalam jumlah besar , seringkali dalam kisaran gigabyte atau terabyte. Database berpotensi jauh lebih besar daripada jumlah RAM yang tersedia di server yang menyimpannya. Karena tidak ada yang pernah membutuhkan semua data dalam database sekaligus, database harus dioptimalkan untuk pengambilan cepat dari subset selektif data mereka: ini adalah tujuan SELECTpernyataan itu, dan database relasional serta solusi NoSQL mengoptimalkan format penyimpanan internal mereka dengan cepat pengambilan subset tersebut.

XML, bagaimanapun, tidak benar-benar cocok dengan persyaratan ini. Karena struktur tag bersarang, tidak mungkin untuk menentukan di mana dalam file nilai tertentu disimpan (dalam hal byte diimbangi ke dalam file) tanpa berjalan di seluruh pohon dokumen, setidaknya hingga kecocokan. Database relasional memiliki indeks, dan mencari nilai dalam indeks, bahkan dengan implementasi pencarian biner primitif, adalah pencarian O (log n) tunggal, dan kemudian mendapatkan nilai aktual hanyalah pencarian file (misalnya pencarian file (misalnya pencarian file) fseek(data_file_handle, row_index * row_size)), yaitu O (1). Dalam file XML, cara yang paling efisien adalah menjalankan parser SAX di atas dokumen Anda, melakukan banyak sekali pembacaan dan pencarian sebelum Anda mendapatkan data aktual Anda; Anda hampir tidak bisa mendapatkan ini lebih baik daripada O (n), kecuali jika Anda menggunakan indeks, tetapi kemudian, Anda harus membangun kembali seluruh indeks untuk setiap penyisipan (lihat di bawah).

Memasukkan lebih buruk. Database relasional tidak menjamin urutan baris, yang berarti mereka hanya dapat menambahkan baris baru, atau menimpa baris yang ditandai sebagai 'dihapus'. Ini sangat cepat: DB bisa menyimpan kumpulan lokasi yang dapat ditulisi; mendapatkan entri dari kolam adalah O (1) kecuali kolam itu kosong; kasus terburuk, kumpulan ini kosong dan halaman baru harus dibuat, tetapi ini juga O (1). Sebaliknya, database berbasis XML harus memindahkan semuanya setelah titik penyisipan untuk memberi ruang; ini O (n). Ketika indeks berperan, hal-hal menjadi lebih menarik: indeks basis data relasional yang khas dapat diperbarui dengan kompleksitas yang relatif rendah, misalnya O (log n); tetapi jika Anda ingin mengindeks file XML Anda, setiap penyisipan berpotensi mengubah lokasi pada-disk dari setiap nilai dalam dokumen, jadi Anda harusbangun kembali seluruh indeks . Ini juga berlaku untuk pembaruan, karena memperbarui, katakanlah, konten teks elemen, dapat mengubah ukurannya, yang berarti XML berturut-turut harus bergeser. Database relasional tidak harus menyentuh indeks sama sekali jika Anda memperbarui kolom yang tidak diindeks; database XML harus membangun kembali seluruh indeks untuk setiap pembaruan yang mengubah ukuran simpul XML yang diperbarui.

Itu adalah kerugian paling penting, tetapi ada lebih banyak. XML sangat verbose, yang bagus untuk komunikasi server-ke-server, karena menambah keamanan (server penerima dapat melakukan segala macam pemeriksaan integritas pada XML, dan jika ada yang salah dalam transfer, dokumen tidak mungkin divalidasi ). Namun, untuk penyimpanan massal, ini mematikan: tidak jarang memiliki 100% atau lebih overhead untuk data XML (tidak jarang untuk melihat rasio overhead dalam kisaran 1000% untuk hal-hal seperti pesan SOAP), sementara penyimpanan DB relasional yang khas skema hanya memiliki overhead konstan untuk metadata tabel, ditambah sedikit per baris; sebagian besar overhead dalam database relasional berasal dari lebar kolom tetap. Jika Anda memiliki data terabyte, overhead 500% benar-benar tidak dapat diterima, karena berbagai alasan.

XML buruk untuk penyimpanan data. Pertama, sangat verbose. Data yang disimpan dalam file XML akan membutuhkan lebih banyak ruang disk daripada data yang sama yang disimpan dalam sistem basis data yang masuk akal. Dalam catatan XML, nama bidang tertentu akan disimpan dua kali, bersama dengan representasi string dari data. Jadi, misalnya, untuk menyimpan integar tunggal dalam bidang yang disebut "foobar", Anda berakhir dengan string 19 byte ini:

<foobar>42</foobar>

Di sisi lain, database nyata akan menyimpan ini sebagai nilai integar tunggal, dengan mengambil 4 byte. Jika database Anda kecil, itu tidak berarti banyak, tetapi jika Anda memiliki 10.000 catatan, itu masalah.

Kedua, XML harus diurai dari teks setiap kali file dibaca. Untuk bidang di atas, database nyata hanya membaca data biner ke dalam memori dari offset yang diketahuinya menyimpan bidang "foobar". Jika file disimpan sebagai XML, ia harus membaca bidang "foobar", parsing teks itu , tentukan bidang apa itu, lalu uraikan string "42" dan ubah menjadi biner 42.

Dengan demikian hukuman kinerja untuk menggunakan XML sangat besar. Manfaat XML adalah bahwa hal itu terbaca oleh manusia, dan memungkinkan transfer data yang mudah antara sistem yang sepenuhnya terpisah. Tak satu pun dari keuntungan itu berlaku untuk database lokal.

Satu-satunya pengecualian adalah file konfigurasi, yang umumnya kecil, dan umumnya perlu diedit oleh manusia.

Database XML benar-benar akan lebih besar dan lebih lambat dari sistem SQL yang masuk akal Kecuali Anda dapat menemukan keunggulan penyeimbang dalam keterbacaan manusia atau interoperabilitas, tidak ada gunanya menggunakannya untuk penyimpanan data.

XML layak tergantung pada konteksnya. Jika data Anda cukup statis, dan tidak banyak berubah (Contoh data misalnya), ya XML adalah penggunaan yang baik.

Pengaturan konfigurasi, data sampel (meskipun jutaan baris, tetapi jarang berubah), semuanya menggunakan XML dengan baik.

Baca / tulis hard disk mahal, jauh lebih dari mengakses data dari tumpukan Oracle / Sql.

Ini tampaknya benar-benar menekankan bahwa XML tidak boleh digunakan untuk penyimpanan data dan seharusnya hanya digunakan untuk program untuk program interoperabilitas.

Premis Anda cacat.

Paragraf yang Anda kutip sebenarnya mengatakan bahwa XML bukan pengganti untuk database , bukan seharusnya tidak digunakan untuk penyimpanan data .

Jelas bahwa file pengaturan tidak sama dengan database, dan teknologi yang berbeda dapat (dan harus?) Digunakan.

Perbaiki saya jika saya salah, tetapi Anda tampaknya memiliki lebih banyak pengalaman dengan bahasa mark-up daripada basis data. Jika Anda memiliki sedikit pengalaman dengan database, Anda akan menyadari domain mana yang cocok untuk dua teknologi berbeda.

Ini sangat subyektif. Kutipan itu, seperti, pendapat seseorang, man.

Jujur, saya pikir XML adalah alternatif yang layak untuk database karena memiliki beberapa keunggulan dibandingkan RDMS, termasuk overhead yang rendah, yang sama dengan penyimpanan yang lebih murah (terutama ketika menggunakan layanan hosting yang membebankan biaya untuk database secara terpisah).

Lihatlah dasBlog dan BlogEngine . Kedua aplikasi tersebut menggunakan xml untuk penyimpanan sebagai default.

Itu kata. Ini bukan RDMS, dan jika Anda memiliki volatilitas tinggi (banyak pembaruan, menyisipkan, atau menghapus) dalam data Anda atau memerlukan ketersediaan tinggi, gunakan database. XML baik-baik saja untuk menyimpan hal-hal kecil seperti data konfigurasi dan data volatilitas rendah.

pertanyaan saya adalah, Apakah ini masih pernyataan yang valid dan apakah sekarang dapat diterima untuk menyimpan data menggunakan XML?

Saya melihat poin Anda pada Anda contoh tentang file konfigurasi .NET. Namun, format file lain apa pun bisa digunakan. Bahkan, di masa lalu, pengaturan seperti itu dulu disimpan dalam file teks biasa yang disebut file INI.

Saya melihat bahwa pernyataan yang Anda berikan dalam warna abu-abu, valid dan benar jika Anda mendefinisikan database sebagai sistem perangkat lunak.

Definisi XML dalam XML-Definition menyatakan bahwa "(XML) adalah bahasa markup yang mendefinisikan seperangkat aturan untuk menyandikan dokumen dalam format yang dapat dibaca manusia dan dapat dibaca mesin."

Definisi ini berfokus pada keterbacaan dan bahasa daripada pada mekanisme untuk mengelola data.

Dibandingkan dengan RDBMS, XML tidak menyediakan sarana untuk secara acak memasukkan dan menghapus baris dalam file XML. Misalnya, jika Anda memiliki 10.00000 baris, dan Anda ingin menghapus baris secara acak bahkan dalam satu lingkungan pengguna, file berbasis XML tidak akan menjadi pilihan yang baik untuk database. Juga, XML tidak menyediakan mekanisme asli untuk mengunci data. Faktanya, karena XML bukan perangkat lunak, semua properti ACID (atomisitas, konsistensi, isolasi, daya tahan) yang menjamin bahwa transaksi basis data diproses secara andal dalam lingkungan bersama diserahkan kepada pengembang untuk membangun (dengan pengecualian Durabilitas). XML tidak memiliki spesifikasi kuat untuk menangani integritas data di seluruh file XML, apalagi server yang berbeda (mis. File pelanggan xml dan pesanan file xml - Tidak ada FK untuk menegakkan integritas).

Di atas bukanlah penghitungan kekurangan XML, sebaliknya, itu bisa server sebagai pembenaran cepat pernyataan bahwa XML bukan perangkat lunak database .

XML tidak pernah dimaksudkan sebagai database atau menggantinya.

XML terutama didefinisikan untuk dokumen Web yang allows for the creation of customized tags for individual information fields.Namun, Anda tidak akan pernah mencapai manajemen data terpusat relasional dengannya.

Mengapa Anda sebenarnya ingin menggunakan XML untuk menyimpan data ? Maksudku, itu bahasa setelah semua ...

Meskipun orang dapat berargumen bahwa ini adalah format yang fleksibel dan mudah dipahami, itu hanya berlaku ketika Anda harus melakukan pengeditan manual pada file. Ketika Anda benar-benar berinteraksi dengan database dengan antarmuka umum (mengambil data X yang memenuhi persyaratan Y dan Z, menyimpan / memperbarui data X, ...) keuntungan itu menjadi batal.

Jawaban singkat: Tergantung.

Jawaban panjang: Dari sudut pandang saya, ini sangat tergantung pada jumlah data yang ingin Anda simpan. Misalnya jika Anda memiliki beberapa objek dalam aplikasi Anda selama runtime dan Anda ingin menyimpannya setelah menjalankan alat, file XML baik-baik saja. Namun, jika toko web Anda memiliki 5.000 pelanggan dan bahkan lebih banyak pesanan, basis data akan menjadi penyimpanan data yang lebih tepat.

Selain itu saya pikir menyimpan pengaturan dalam database dan tidak dalam file seperti app.config dalam banyak kasus tidak terlalu berguna, tapi saya tidak berpikir contoh ini membuktikan kutipan salah.

XML adalah pilihan yang sangat baik untuk pengaturan konfigurasi. Tidak hanya file XML mudah diurai / sorot dalam IDE, mereka juga sangat mudah untuk diedit oleh non-programmer. Saya menemukan mereka sangat berguna dalam skenario pengembangan web di mana tugas pemeliharaan sedang dilakukan oleh desainer dan manajer konten.

XML biasanya tidak boleh digunakan sebagai sumber data primer untuk aplikasi non-sepele. Serialisasi / deserialisasi overhead saja meminta solusi yang berbeda.

Istilah basis data dapat merujuk pada data mentah saja, atau sistem manajemen basis data juga. Definisi ini membuat perbedaan besar dalam keseluruhan argumen.

Jika kita menggunakan definisi RDBMS, maka XML memiliki arti yang sangat sedikit. Anda mendapatkan sangat sedikit dalam hal jaminan ACID (Anda harus menulis kode Anda sendiri untuk menyelesaikannya). Jika Anda membutuhkannya (dan sebagian besar sistem transaksional melakukannya), Anda sudah berada dalam masalah besar. Saya bisa memberikan daftar ratusan fitur yang diterima begitu saja dengan RDBMSes, yang harus Anda temukan kembali dan laksanakan kembali. Pikirkan model keamanan, replikasi, cadangan, hanya untuk beberapa nama dasar.

Dalam pengertian di atas, tidak, XML bukan database, dan Anda tidak boleh mencoba menggunakannya sebagai satu.

Jika kita menggunakan definisi "data mentah", tarif XML jauh lebih baik, tetapi masih belum terlalu bagus. Seperti yang orang lain tunjukkan, ini sangat bertele-tele secara umum, biasanya tidak memiliki penyandian biner, dan memiliki tag duplikat, dll. Ini adalah kompromi yang dibuat agar XML dapat dibaca oleh manusia - pada dasarnya, efisiensi adalah musuh dari persyaratan ini . XML juga tidak cocok untuk situasi paling sederhana di mana Anda memasukkan catatan secara terus menerus. Dengan asumsi Anda ingin file XML Anda menjadi valid, Anda memerlukan tag penutup tunggal, yang berarti menambahkan catatan berarti Anda perlu menggeser tag pada akhirnya. Ini cukup mahal (bagaimana kita tahu di mana tag itu dimulai? Bagaimana jika ada beberapa "tabel", apakah kita hanya memindahkan seluruh file?), Dan jika Anda ingin mengatasinya, Anda

Ada situasi di mana XML sesuai - file config adalah contoh yang bagus, karena mereka biasanya kecil dan keterbacaan manusia adalah fitur yang sangat baik untuk dimiliki. Memiliki database hanya untuk file konfigurasi mungkin berlebihan.

Database, di sisi lain, sangat bagus ketika Anda memiliki ribuan (atau jutaan / milyaran) catatan, dan memiliki banyak pengguna secara bersamaan memperbaruinya. Jadi ya, XML bukan database, dan Anda tidak boleh menggunakannya seperti itu. Contoh Anda adalah salah satu situasi di mana Anda tidak memerlukan DB di tempat pertama, dan XML lebih cocok.

Cara saya melihatnya adalah ini: jika Anda menggunakan XML sebagai DB (katakanlah, sebagai backing store untuk sistem transaksional), Anda akhirnya akan menemukan kembali dan menulis ulang RDBMS . Itu cara yang sangat buruk untuk menghabiskan waktu dan energi Anda. Saya pikir inilah yang dikatakan oleh kutipan itu.

Saya setuju bahwa ini bukan basis data relasional. Saya pikir penulis hanya mengatakan dalam kutipan untuk tidak menggunakannya sebagai satu.

Karena itu meskipun Anda mungkin atau mungkin tidak membutuhkannya. Jika Anda benar-benar tidak perlu melakukan banyak pencarian pada data, dan hanya bermaksud menyimpannya dan kemudian mengambilnya berdasarkan beberapa kriteria permintaan terbatas maka Anda memerlukan penyimpanan dan pengambilan XML DOCUMENT - bukan database relasional.

Ada banyak aplikasi yang hanya perlu menyimpan dokumen dengan data di dalamnya untuk pengambilan secara keseluruhan nanti. Jika ini masalahnya maka tidak berguna untuk membuat skema berbasis SQL, parsing XML, dan kemudian serialkan ke database hanya untuk melakukan hal sebaliknya nanti. Ada banyak overhead kode yang berpotensi terlibat dalam melakukan itu. Ada yang lebih sedikit jika Anda melakukannya dengan benar.

Anda dapat menggunakan alat-alat ORM seperti Hibernate dan alat-alat seperti Apache Axis untuk membuat autogenerasi secara praktis semua kode yang Anda perlukan untuk membangun layanan yang hanya menangani operasi CRU sederhana. Anda harus membungkusnya dalam otentikasi tentu saja, dan mungkin mungkin ingin memisahkan data berdasarkan pengguna, tingkat akses, dll. Anda bahkan mungkin ingin membatasi operasi yang diizinkan dilakukan pengguna tertentu melalui layanan SOAP untuk contoh.

Dalam hal ini Anda melakukan lebih seperti manajemen konten daripada yang lain.