Bu alıntı, XML'i genel olarak bir depolama biçimi olarak kullanmakla ilgili değildir (gereksinimlere bağlı olarak iyi), ancak veritabanı tipi depolama için.
İnsanlar veritabanları hakkında konuşurken , genellikle gigabayt veya terabayt aralığında büyük miktarlarda veri depolayan depolama sistemleri anlamına gelir . Veritabanı, potansiyel olarak onu depolayan sunucudaki kullanılabilir RAM miktarından çok daha büyüktür. Hiç kimse bir veritabanındaki tüm verilere bir kerede ihtiyaç duymadığından, veritabanları, verilerin seçici alt kümelerinin hızlı bir şekilde alınması için optimize edilmelidir: SELECTifadenin amacı budur ve ilişkisel veritabanları ve NoSQL çözümleri dahili depolama formatlarını hızlı bir şekilde optimize eder bu alt kümelerin alınması.
Ancak XML bu gereksinimlere tam olarak uymuyor. İç içe etiket yapısı nedeniyle, belirli bir değerin dosyada nerede saklandığını (bir dosyaya bayt uzaklığı açısından) en azından eşleşmeye kadar tüm belge ağacını yürümeden belirlemek mümkün değildir. İlişkisel bir veritabanı dizinlere sahiptir ve bir ilkel ikili arama uygulamasında bile bir dizinde bir değere bakmak tek bir O (log n) aramasıdır ve daha sonra gerçek değerlere ulaşmak bir dosya aramasından başka bir şey değildir (ör. fseek(data_file_handle, row_index * row_size)), O (1) 'dir. Bir XML dosyasında, en etkili yol belgeniz üzerinde bir SAX ayrıştırıcı çalıştırmak ve gerçek verilerinize ulaşmadan önce çok fazla okuma ve arama yapmaktır; dizinleri kullanmadığınız sürece bunu O (n) 'den daha iyi elde edemezsiniz, ancak daha sonra her ekleme için dizinin tamamını yeniden oluşturmanız gerekir (aşağıya bakın).
Eklemek daha da kötü. İlişkisel veritabanları satır sırasını garanti etmez, bu da yeni satırlar ekleyebilecekleri veya 'silinmiş' olarak işaretlenmiş satırların üzerine yazabilecekleri anlamına gelir. Bu son derece hızlı: DB sadece yazılabilir konumların bir havuzunu tutabilir; havuz boş olmadığı sürece havuzdan giriş almak O (1) 'dir; en kötü durumda, havuz boş ve yeni bir sayfa oluşturulması gerekiyor, ancak bu da O (1). Aksine, XML tabanlı bir veritabanı yer açmak için ekleme noktasından sonra her şeyi taşımak zorunda kalacaktır; bu O (n). Dizinler devreye girdiğinde, işler daha da ilginç hale gelir: tipik ilişkisel veritabanı dizinleri nispeten düşük karmaşıklıkla güncellenebilir, örneğin O (log n); ancak XML dosyalarınızı dizine eklemek istiyorsanız, her ekleme potansiyel olarak belgedeki her değerin diskteki konumunu değiştirir, bu nedenledizinin tamamını yeniden oluşturun . Bu, güncellemeler için de geçerlidir, çünkü bir öğenin metin içeriğinin güncellenmesi boyutunu değiştirebilir, bu da ardışık XML'nin değişmesi gerektiği anlamına gelir. İlişkilendirilmemiş bir veritabanının dizine eklenmemiş bir sütunu güncelleştirirseniz dizine hiç dokunması gerekmez; bir XML veritabanının, güncellenen XML düğümünün boyutunu değiştiren her güncelleştirme için tüm dizini yeniden oluşturması gerekir.
Bunlar en önemli dezavantajları, ancak daha fazlası var. XML çok ayrıntılıdır, bu da sunucudan sunucuya iletişim için iyidir, çünkü güvenlik ekler (alıcı sunucu XML üzerinde her türlü bütünlük kontrolünü gerçekleştirebilir ve aktarımda bir sorun varsa, belgenin doğrulanması olası değildir ). Bununla birlikte, yığın depolama için bu öldürücüdür: XML verileri için% 100 veya daha fazla ek yüke sahip olmak nadir değildir (SOAP mesajları gibi şeyler için% 1000 aralığında genel oranların görülmesi nadir değildir), tipik ilişkisel DB depolama şemaların tablo meta verileri için yalnızca sabit bir ek yükü ve ayrıca satır başına küçük bir biti vardır; ilişkisel veritabanlarındaki ek yükün çoğu sabit sütun genişliklerinden gelir. Terabaytlık bir veriye sahipseniz, birçok nedenden dolayı% 500'lük bir ek yük kabul edilemez.