"Плохо" хранить XML в базе данных?

Ответ 1

Это неплохо. Microsoft SQL Server имеет тип данных XML. Одним из вариантов использования XML является ситуация, в которой мы оказались. Для каждой строки в конкретной таблице нам нужно было сохранить переменное количество атрибутов, связанных с этой строкой. И число этих атрибутов может меняться со временем и с каждой строкой. Мы нашли более эффективным сохранение этих атрибутов и их значений в формате XML. В будущем, каждый раз, когда мы корректируем количество атрибутов, нам не нужно создавать изменения схемы.

Ответ 2

Здесь есть некоторые действительно глупые ответы - просто потому, что база данных поддерживает тип данных, не означает, что вы должны ее использовать. Эти вещи неизменно добавляются как функции, потому что конкуренция имеет их, а не потому, что они правильные вещи. Глобальные переменные? Триггеры? Кто-нибудь хотел бы защитить их только потому, что вы можете использовать их, и они там?

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

XML - это протокол передачи данных; как правильно сказал GolezTrol: "Это способ экспортировать (и импортировать) данные" - т.е. это просто накладные расходы, используемые для облегчения связи структуры данных между различными системами. После получения теги должны быть удалены, а данные (и только данные) сохранены в вашем исходном двигателе базы данных, независимо от того, что может быть. Не сам XML. Накладные расходы для XML составляют ~ 10 раз, чем данные, которые он описывает. Хотите сказать своему боссу, почему 100 ГБ данных занимают 1 ТБ пространства на гипервысокой SAN? Или взять всю ночь на резервное копирование по насыщенной сетевой ссылке? Или вызвать проблемы с производительностью в производстве? Если вы не проанализируете данные из бессмысленных тегов, вы просто поднимете проблему и текущие ежедневные затраты на поддержку на оперативную поддержку в течение следующих десяти лет. Неряшливый, неряшливый, неряшливый. Это позволяет поставщикам, таким как EMC, работать в бизнесе.

XML - это метаданные. Ничего умного, просто дескриптор схемы. После того, как он был перенесен и проанализирован, он потерял свою полезность и стал просто беспорядком, который забивает любую базу данных, которую вы используете. Избавьтесь от этого, если вы не навязчиво не склонны к хеджированию вчера бессмысленных дрянных метаданных описания, хранящихся много раз. Вставай. Это типичный синдром "Императорская новая одежда", перестало быть связанным чем-то простым и одноразовым. Это только метаданные, и его не следует хранить или поклоняться, это мусор, как только он разбирается. И что лучше? Разбирать его один раз или бесполезно анализировать его каждый раз, когда вам нужны данные из него? Ответ, который мне приписывал, был очевидным.

Ответ 3

Хранение XML, JSON, YAML, разделенных запятыми списков, двоичных blobs или чего-либо еще в базе данных не является bad... per se.

Это может указывать на недостаточное понимание того, что представляет собой база данных (хранение данных, относящихся к другим данным), и вызывает в воображении видения баз данных с таблицами с одним столбцом, которые называются data1, data2 и т.д.... с каждой строкой таблицы, содержащей запись +5 МБ реляционных данных, кодированных XML.

С другой стороны, для такой структуры существует множество действительных случаев - быстро изменяющиеся конфигурации могут быть представлены в JSON и сохранены в таблице с двумя столбцами, структурированной следующим образом:

dbo.good_table
ApplicationID (bigint)
Configuration (varchar(max))

Разница между приведенной выше таблицей и таблицей выглядит следующим образом:

dbo.bad_table
ApplicationID (bigint)
ApplicationMembers(xml)

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

Ответ 4

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

Существуют базы данных XML, но они также не хранят данные в XML. Они просто обеспечивают способ сохранения и загрузки иерархических данных (XML - это иерархическая структура), а не стандартная структура таблицы.

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

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

Ответ 5

Нет, это не так.

Фактически несколько баз данных уже имеют типы данных для хранения XML-документов

Ответ 6

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