Ця цитата не стосується використання XML як формату пам’яті взагалі (для цього це добре, залежно від вимог), а для зберігання у базі даних.
Коли люди говорять про бази даних, вони зазвичай мають на увазі системи зберігання даних, які зберігають величезну кількість даних, часто в діапазоні гігабайт або терабайт. База даних потенційно набагато більша, ніж кількість доступної оперативної пам’яті на сервері, який її зберігає. Оскільки нікому ніколи не потрібні всі дані в базі даних одразу, бази даних повинні бути оптимізовані для швидкого пошуку селективних підмножин їх даних: саме для цього потрібне SELECTтвердження, а реляційні бази даних, а також рішення NoSQL оптимізують свій внутрішній формат зберігання для швидкого пошуку пошук таких підмножин.
Однак XML не відповідає цим вимогам. Зважаючи на вкладену структуру тегів, неможливо визначити, де у файлі зберігається певне значення (з точки зору зміщення байтів у файл) без проходження всього дерева документів, принаймні до відповідності. Реляційна база даних має індекси, і пошук значення в індексі навіть з примітивною реалізацією бінарного пошуку - це єдиний пошук O (log n), а потім дійти до фактичних значень - це не що інше, як пошук файлу (наприклад, fseek(data_file_handle, row_index * row_size)), що є O (1). У XML-файлі найефективніший спосіб - запустити аналізатор SAX над вашим документом, виконуючи дуже багато читань і пошуків, перш ніж дійти до фактичних даних; Ви навряд чи зможете отримати це краще, ніж O (n), якщо ви не використовуєте індекси, але тоді вам доведеться перебудувати весь індекс для кожної вставки (див. нижче).
Вставлення ще гірше. Реляційні бази даних не гарантують порядок рядків, а це означає, що вони можуть просто додавати нові рядки або замінювати будь-які рядки, позначені як "видалені". Це надзвичайно швидко: БД може просто зберігати пул записуваних місць навколо; отримання запису з пулу - O (1), якщо басейн не порожній; в гіршому випадку пул пустий, і повинна бути створена нова сторінка, але це теж O (1). На противагу цьому, база даних на основі XML повинна буде перемістити все після точки вставки, щоб звільнити місце; це О (п). Коли індекси починають грати, речі стають ще цікавішими: типові індекси реляційних баз даних можуть бути оновлені з відносно низькою складністю, скажімо, O (log n); але якщо ви хочете проіндексувати свої XML-файли, кожна вставка потенційно змінює розташування на диску кожного значення в документі, тож вам доведетьсявідновити весь індекс . Це стосується також оновлень, оскільки оновлення, скажімо, текстового вмісту елемента може змінити його розмір, а це означає, що послідовний XML повинен змінюватися. Реляційна база даних зовсім не повинна торкатися індексу, якщо ви оновлюєте неіндексований стовпець; база даних XML повинна була б відновити весь індекс для кожного оновлення, що змінює розмір оновленого вузла XML.
Це найважливіші недоліки, але їх більше. XML є дуже багатослівним, що добре для зв'язку між сервером і сервером, оскільки це забезпечує безпеку (сервер, що приймає, може виконувати всілякі перевірки цілісності XML, і якщо щось перейшло не так у передачі, документ навряд чи буде підтверджений ). Однак для масового зберігання це вбивство: не рідкість мати 100% або більше накладних даних для XML-даних (не рідкість бачити накладні коефіцієнти в діапазоні 1000% для таких речей, як SOAP-повідомлення), а типові реляційні сховища БД схеми мають лише постійні накладні витрати на метадані таблиці плюс мініатюрний біт на рядок; більша частина накладних витрат у реляційних базах даних відбувається з фіксованої ширини стовпців. Якщо у вас є терабайт даних, 500% накладні витрати з багатьох причин просто неприйнятні.