Хранение данных в формате XML - PullRequest
4 голосов
/ 27 августа 2009

В каких случаях хранение данных в формате XML предпочтительнее СУБД и почему?

Можете ли вы привести аналогию?

Ответы [ 10 ]

5 голосов
/ 27 августа 2009

Резюме

Если у вас мало данных и вы полностью контролируете их (нет зависимых третьих сторон), XML - хороший вариант. В противном случае СУБД - см. Ниже для большего количества причин.

Аналогия

Если СУБД - это шкаф для хранения документов (ящики записей одинакового размера, организованные по некоторому индексу), то XML - это рюкзак (необязательно организованный пакет записей произвольного размера, может торчать по углам).

Причины для XML

1) Гибкость

Если ваша схема либо очень слабая, либо со временем изменяется, то XML предпочтительнее, поскольку управление версиями СУБД затруднено, если в нем есть данные. По моему опыту, запросы XML Serialization, XSLT и XPath устойчивы к изменениям в схеме XML и могут продолжать работать для старых / новых клиентов. Например, вы можете добавить некоторые новые элементы в документ, а старый EXE-файл, который читает этот документ, просто игнорирует эти элементы. Запрос RDBMS, который выполняет «SELECT * FROM table», в который вы только что добавили столбец, будет иметь неопределенные результаты.

2) Развертывание

Легко - просто отправьте свой EXE.

3) Отладка

Легко «отлаживать» данные - XML ​​уже может быть читаемым человеком; в противном случае XSLT может сделать его более читабельным.

4) Совместимость

Вы можете передавать XML другим системам, и все равно, какую платформу / технологию они используют.

Причины СУРБД

1) Производительность

Если у вас много данных, то функции индексации СУБД обеспечат вам наилучшую производительность. Чтение большого XML (> 1000 записей) стоит дорого, если вы просто пытаетесь найти запись с ID = 123, что может сделать СУБД в одно мгновение. Хранимые процедуры сделают это еще лучше.

2) Безопасность

Вы можете защитить части СУБД через разрешения - например, предоставить / запретить доступ SELECT для различных пользователей.

3) Бизнес-инструменты

Существует множество инструментов RDBMS для таких вещей, как OLAP и отчетность.

2 голосов
/ 27 августа 2009

Я был бы очень осторожен, потому что XML не является устройством хранения данных. XML - это метаязык, язык для создания языков. XML часто неправильно используют в качестве устройства хранения данных, но эта частота не позволяет доверять ошибочному пониманию технологии.

Я слышал, как кто-то пытался доказать это, утверждая, что метаязык означает язык данных о данных, который все еще не является устройством хранения данных. Язык, созданный для представления описания структуры данных, не является языком самих данных, и хотя экземпляр языка может быть структурой, созданной из данных, сам язык не является.

Если ваше намерение не состоит в том, чтобы создать язык или представлять язык для класса данных, я бы не рекомендовал использовать XML, поскольку результат будет раздутым, медленным, и вы вряд ли будете использовать какие-либо вспомогательные технологии, которые делают XML действительно мощный. В качестве альтернативы другие упомянули YAML и JSON, которые значительно легче. Я бы порекомендовал попробовать один из них. Если метаданные и их структура / отношения важнее для вас, чем сами данные, тогда я бы придерживался XML, потому что потенциал для обработки и манипулирования невероятно расширяем.

2 голосов
/ 27 августа 2009

Я бы никогда не предпочел хранить в базе данных много XML файлов данных.

XML подходит для удобочитаемых и расширяемых форматов файлов, например, когда вы сохраняете в приложении. XML предпочтительнее, так как позволяет любому другому использовать этот формат файла.

В другой раз XML предпочтительнее для настроек конфигурации. Например, я много занимаюсь программированием игр и для меня было бы безумием хранить настройки игрового процесса в базе данных. XML (или любой файл в этом отношении) намного проще.

Однако, учитывая записи (данные в записях), такие как продукты или клиенты, вы были бы очень неправы, предпочитая что-то другое, чем база данных для хранения этих данных. Резервное копирование, скорость и масштабируемость - вот три примера, почему.

Так что ответ - это зависит .

Вы должны быть судьей и сделать правильный вызов.

Что касается аналогии:

" XML похож на tupperware. Если вы пошли за покупками и добрались до дома, да, вы могли бы положить каждый предмет в коробку для хранения под заказ, но в конце дня, вероятно, проще просто положить вещи в холодильник. ."

XML имеет свое место, как я уже упоминал выше.

2 голосов
/ 27 августа 2009

Если данные могут быть естественно описаны в древовидной структуре, XML может быть в порядке. Я бы предпочел более легкую альтернативу. YAML и JSON являются кандидатами.

0 голосов
/ 04 декабря 2009

Здесь много хороших ответов, но все они упускают самый важный момент. Большая проблема, которую решает для вас реляционная база данных, - это синхронизация многопользовательского доступа. Для однопользовательской программы вы можете при загрузке прочитать все в память из набора файлов XML и записать все заново при сохранении - если вы можете сначала найти рынок для однопользовательского программного обеспечения. В общем случае многопользовательского доступа это решение не будет работать, и если вы начнете возиться с мелкозернистой блокировкой, вы в основном собираетесь повторить около 30 лет работы, которая уже сделана для вас, если вы используете реляционная база данных.

0 голосов
/ 28 августа 2009

Полагаю, вы имеете в виду «XML в последовательном текстовом файле». В противном случае это на самом деле не тот или другой вопрос: вы можете хранить XML в реляционной базе данных, вы можете экспортировать реляционную базу данных в XML и т. Д. Это говорит ...

XML отлично подходит для сложных потоков данных с непредсказуемыми данными. Как текстовый файл: в любой момент может быть целесообразно начать новую главу, включить сноску, переключиться на курсив и т. Д. Обычно не следует ожидать, что в каждой главе будет одинаковое количество сносок, или даже если в каждый текстовый документ будет включено сноски. Вы не ожидаете, что в каждом документе будет шесть слов простого текста, за которыми следуют три слова курсивом, за которыми следует сноска и т. Д. XML позволяет тегам встречаться очень гибко.

Реляционные базы данных отлично подходят для данных в согласованных форматах. Например, для заказа клиента вы ожидаете иметь имя клиента, адрес, заказанный товар, цену и т. Д. Заказ без указания клиента почти наверняка не будет обработан.

Многие люди сегодня используют XML для хранения и передачи всех данных. Я думаю, что это большая ошибка. XML не только очень громоздок для данных, которые поступают в предсказуемых форматах - так называемый «брекет-налог», - но также создает всевозможные возможности для ошибок. Фиксированный формат, такой как CSV, не позволяет даже сказать, что вам нужны два имени клиента в одном заказе. Есть только одно место, чтобы положить его, нет способа поставить его дважды. Но в XML вы можете включить два тега или атрибута «заказчика». CSV не дает возможности указать неопределенные атрибуты. Имя покупателя не указано курсивом или цена указана в килограммах. Но в XML может быть любой произвольный набор атрибутов. Таким образом, программа, пытающаяся обработать поток XML для фиксированных данных, должна обрабатывать всевозможные возможные ошибки, которые даже не появляются в других форматах.

0 голосов
/ 27 августа 2009

В основном XML предпочтительнее базы данных для записи настроек / настроек приложения. Я предполагаю это, потому что, 1. Повредить файлы базы данных проще 2. Поддержка XML кроссплатформенности.

0 голосов
/ 27 августа 2009

Я использую XML трудно. В дополнение к http://commons.apache.org/digester/ это мощный источник. Только мои 2 цента.

0 голосов
/ 27 августа 2009

Я бы сохранил XML в базе данных, если я уже получил его в виде XML (например, от вызова веб-службы или чего-то в этом роде) и мне нужно было бы где-то сохранить "оригинальную" копию данных.

Я мог бы также сохранить что-то в XML, которое является высоко иерархическим и / или только частично структурированным, что-то, что просто неудобно и сложно выразить в строках / столбцах, в которых превосходит обычная таблица RDBMS.

Как правило, всякий раз, когда вам нужно обработать информацию в вашей базе данных или приложениях, используя вашу базу данных, это легче сделать, если она находится в реляционных таблицах. Поэтому, если у вас нет действительно веской причины использовать XML, не используйте его, потому что вам лень создавать несколько таблиц.

У XML есть свои достоинства и все - но в целом он довольно многословен, время от времени немного громоздок (гораздо проще ВЫБРАТЬ в столбце таблицы, чем в XML, чтобы получить значение), и в целом обычно медленнее, чем использование реляционных таблиц сразу.

SELECT fieldName 
FROM table

легче использовать, читать и понимать, чем

SELECT 
   xmlData.value('(xpath-expression)[1]', 'int') as 'Field'
FROM table

Итак, подведем итог: используйте его, если вы действительно видите необходимость и выгоду, но не переусердствуйте (только потому, что можете, или потому что это круто или сексуально). Используйте с осторожностью и по уважительным причинам.

Марк

0 голосов
/ 27 августа 2009

Если вам нужно переместить их в совместимом, доступном для человека формате или если концептуальная модель ваших данных не так легко следует реляционной модели.

Кроме того, если ваше приложение хочет хранить данные в удобном для анализа, но все еще расширяемом формате. Взять к примеру браузер. Я хотел бы хранить данные закладок в файле XML, а не в реляционной таблице.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...