Каковы преимущества хранения XML в реляционной базе данных?

Сегодня я копался в базе данных AdventureWorks и заметил, что в ряде таблиц ( HumanResources.JobCandidateи, Sales.Individualнапример,) есть столбец, в котором хранятся данные XML.

Я хотел бы знать, что является преимуществом хранения в основном данных строки таблицы базы данных в столбце другой таблицы? Разве это не затрудняет запрос этой информации? Или предположение, что данные не нужно запрашивать и нужно просто хранить?

Поскольку не все данные должны храниться реляционно, а написание кода для обработки данных, которые вы передали в виде XML для реляционного хранения, занимает много времени (и очень утомительно). Это особенно верно, когда много XML-данных поступает из систем, которые выбрасывают большие общие ответы.

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

Кроме того, SQL Server предоставляет некоторые инструменты и синтаксис «ОК» для работы с XML в T-SQL, так что для специальных запросов это совсем не так, как если бы вы хранили, скажем, содержимое. из CSV.

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

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

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

Разве это не затрудняет запрос этой информации?

SQL Server может запрашивать поля и переменные XML. Не обязательно сложно, но больше работы, да. Но выполнимо.

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

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

Конечно, многие вещи лучше оставить в воображении воображения.

Скажем, электронные медицинские записи, например:

Поскольку вы, скорее всего, сохраните ASCII HL7 V2.x в поле базы данных. Возможно, вы захотите хранить HL7 V3.0 в поле базы данных.

Таким образом, преимущество заключается в удобстве.

В настоящее время я работаю над проектом, который делает это. У нас есть данные, которые должны быть обработаны несколько раз, хранятся реляционно. Тем не менее, обработка выполняется в Java, и там легче работать с XML. Итак, мы делаем однократный проход по реляционным данным и сохраняем их в виде XML в таблице. Затем мы можем обрабатывать эти данные в Java с помощью одного не присоединяющегося запроса, а не извлекать данные каждый раз, и снова и снова обрабатывать одни и те же данные для нашего сердца. Это намного проще и эффективнее.

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

Часто вы получаете смешанные данные как XML, так и реляционные. (Прекрасным примером этого является хранилище документов, где каждый документ может иметь поля метаданных, такие как заголовок, дата создания, владелец и т. Д.)

На данный момент вы должны выбрать один из трех вариантов:

1. Храните все в реляционной БД.
2. Храните все в родной XML-базе данных.
3. Храните данные в двух отдельных БД, XML в собственном XML и метаданные в реляционных.

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

Таким образом, вариант 1 остается не лучшим решением, но, возможно, наименее плохим.

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

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

Надеюсь, это поможет, Джефф

Документно-ориентированные хранилища данных (также известные как NoSql) очень популярны в наши дни:

http://en.wikipedia.org/wiki/Document-oriented_database

Нет причин, по которым вы не можете использовать документно-ориентированную схему в реляционной базе данных. Вы можете не получить все те же преимущества по сравнению с чем-то вроде Mongo, но у вас также не будет недостатков.

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

Контраст , что с Монго, где они только , что в базе данных документов. Но это другая тема.

РЕДАКТИРОВАТЬ: основная идея, ориентированная на документы: вы извлекаете данные, манипулируете ими и помещаете их обратно в одно целое. Иногда, например, когда вы передаете документ клиенту, вы просто хотите отправить все это в виде большого двоичного объекта и позволить им разобраться с этим. Преимущество (и недостаток) - гибкость. Проверка и правильность документа осуществляется вне базы данных.

РЕДАКТИРОВАТЬ РЕДАКТИРОВАТЬ: еще один контраст. Представьте себе сохранение изображений JPG или документов Word в столбце базы данных.

Каковы преимущества хранения дерева (XML) в списке кортежей (таблица базы данных)?

Нет никаких причин, по которым XML не должен запрашиваться вашей СУБД, например, с использованием XPath или SPARQL.

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

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

Что ж, XML (или JSON) довольно хорош для хранения метаданных с иерархией. Какие есть альтернативы? Может быть, таблица метаданных с refid / ключ / значение / глубина? Это немного громоздко (но, вероятно, лучше для запросов, если вам нужно это сделать). Хранение некоторых XML-данных о документе (строка в таблице документов) очень удобно, когда вы хотите сохранить некоторую иерархическую информацию без необходимости полагаться на внешнюю таблицу или добавлять 1 столбец на «тип» информации.

Я бы сказал, что это плохая практика, поскольку вы забиваете эффективное хранилище неэффективными тегами, которые не нужны, если вы попытаетесь разобрать информацию. По сравнению с данными, которые он описывает, XML имеет ужасные накладные расходы на хранение, так как для каждого столбца требуется один тег для каждой строки. Для сравнения, данные, проанализированные и сохраненные в реляционном формате, имеют имя столбца, сохраненное ОДИН РАЗ. Для десятка рядов на устройстве. Я думаю, разработчики предположили, что это масштабируется до миллионов строк. Это может представлять собой сотни ГБ накладных расходов на несколько десятков ГБ данных, что создает операционные проблемы. Вы в основном отрекаетесь от ответственности и толкаете людей, которые должны поддержать написанное вами дерьмо.

Итак, почему бы не хранить его вдали от оперативных данных, в своей собственной базе данных? Или как это задумано - в плоских файлах? Скорее всего, это никогда не будет рассмотрено, так почему бы не убрать его из-за снижения производительности операционной системы? Помните, что XML предназначен ТОЛЬКО для предоставления описания схемы данных, которая в противном случае не была бы очевидна из-за различий в протоколах хранения между системами. В этом весь смысл, в этом нет ничего умного. Хранение 10-кратного объема служебных данных для данного объема данных просто говорит о том, что вы неаккуратный разработчик, который не продумал все и не может быть обработан для обработки данных, которые вы потребляете, в разумном, эффективном и быстром для запроса формате. Перестаньте прилагать усилия к оперативной поддержке и ДУМАЙТЕ о том, как лучше обрабатывать данные после того, как вы мы получили это будет мой звонок. Нет никакой защиты для хранения данных в виде XML после их получения, поскольку они служат своей цели.