Хранение XML в БД (SQL Server)
юзай 2005 sql server. Можно тип столбца объявить как xml, при желании со схемой. В sql можно с такими столбцами использовать xquery.
Сразу напишу, не пробовал, только читал what`s new
Сразу напишу, не пробовал, только читал what`s new
Можно тип столбца объявить как xml, при желании со схемой. В sql можно с такими столбцами использовать xquery.Это не native xml, это всего лишь колонка специального типа
ну почти нейтив -- хранится то оно в отдельном хранилище (наверно 
-- по крайней мере в DB2 это так)
а вообще юзайте Native XML СУБД, например Sedna
-- по крайней мере в DB2 это так)а вообще юзайте Native XML СУБД, например Sedna
native, и даже индексация поддерживается
Что такое native xml, можно почитать тут:
http://en.wikipedia.org/wiki/XML_native_database
http://en.wikipedia.org/wiki/XML_native_database
Я не имел в виду "native xml БД", а имел в виду "native поддержка xml в БД", в ответ на "это всего лишь колонка специального типа" (явно не отражает степень поддержки xml в MSSQL 2005). А определение native xml db (что по твоей ссылке) какое-то странное. ИМХО лучше назвали бы pure xml db, а native xml оставили бы для native support of xml. Кстати не мешало бы сравнить поддержку xml в MSSQL 2005 с поддержкой xml в той же Exist.
а имел в виду "native поддержка xml в БД", в ответ на "это всего лишь колонка специального типа" (явно не отражает степень поддержки xml в MSSQL 2005)В чём разница? Вот например есть какой-нибудь DATETIME, это тип, который можно присвоить колонке. Можно создать индекс по этой колонке, можно вычислять специальные функции от значений этого типа. То же и с XML.
Разница есть, с помощью UDT ты такую поддержку не прикрутишь. В ms sql 2005 когда ты в запросе вызываешь метод query (или как он там планировщик рассматривает такой запрос целиком: наряду с простыми индексами, рассматриваются xml индексы, оценивается селективность как условий в where, так и селективность условий в xquery. Если это не нативная поддержка, то я не знаю.
> Разница есть, с помощью UDT ты такую поддержку не прикрутишь.
О чём это говорит, кроме слабости UDТ (кстати, мог бы и расшифровать, это ведь не общепринятое сокращение)?
> наряду с простыми индексами, рассматриваются xml индексы,
> оценивается селективность как условий в where,
> так и селективность условий в xquery.
Можешь привести показательный пример запроса, а то вдруг я недооценил MSSQL (в рекламном списке фичей очень уж куцое описание)?
О чём это говорит, кроме слабости UDТ (кстати, мог бы и расшифровать, это ведь не общепринятое сокращение)?
> наряду с простыми индексами, рассматриваются xml индексы,
> оценивается селективность как условий в where,
> так и селективность условий в xquery.
Можешь привести показательный пример запроса, а то вдруг я недооценил MSSQL (в рекламном списке фичей очень уж куцое описание)?
А определение native xml db (что по твоей ссылке) какое-то странное. ИМХО лучше назвали бы pure xml db, а native xml оставили бы для native support of xml.Почему обязательно pure? Ключевой момент: нужно автоматическое или полуавтоматическое согласование реляционной модели данных с моделью XML-документа.
То есть если все xpath и xquery-запросы выполняются только на отдельных документах, каждый из которых в своей ячейке лежит - это неинтересно совсем, это всего лишь специальные функции, ну индексы для ускорения придумали, no big deal.
Вот если на целую базу или её существенную часть (затрагивающую данные из нескольких таблиц, и множества записей и колонок в каждой) можно смотреть как на XML-документ - вот тогда интересно. Судя по описанию, MS SQL не умеет такого.
> Вот если на целую базу или её существенную часть
цель какая?
xml, вроде. как раз используется там, где нам тяжело при описанни данных оставаться в реляционной модели
цель какая?
xml, вроде. как раз используется там, где нам тяжело при описанни данных оставаться в реляционной модели
> где нам тяжело при описанни данных оставаться в реляционной модели
вот и пусть не остаются, а не просто рассовывают документы по ячейкам
вот и пусть не остаются, а не просто рассовывают документы по ячейкам
Почему обязательно pure?не знаю, но native xml db -- тупо, это все равно что говорить native ralational db
То есть если все xpath и xquery-запросы выполняются только на отдельных документах, каждый из которых в своей ячейке лежит - это неинтересно совсем, это всего лишь специальные функции, ну индексы для ускорения придумали, no big deal.
no big deal -- ну-ну, один из самых совершенных cost-based планировщиков, с поддержкой xml данных и запросов наравне с реляционными
потом, я не говорил, что в ms sql 2005 xml чисто в lob храниться
вроде там специальный бинарный формат, и для структурированного xml со схемой, там как-то эффективно структурировано хранение (наверно, какая-то реляционная организация) -- не забывай, что они поддерживают расширение xquery для insert, update, delete.
Вот если на целую базу или её существенную часть (затрагивающую данные из нескольких таблиц, и множества записей и колонок в каждой) можно смотреть как на XML-документ - вот тогда интересно.
Как раз смотреть на реляционную базу как на xml документ совсем не интересно, это просто довольно примитивная примочка к существующей БД. Такую примочку сделали еще для ms sql 2000, правда с xpath (xquery тогда еще как такового не было).
> Как раз смотреть на реляционную базу как на xml документ совсем не
> интересно, это просто довольно примитивная примочка к существующей БД.
Так прикол в том, что база уже не чисто реляционной должна получаться.
> вроде там специальный бинарный формат, и для структурированного xml
> со схемой, там как-то эффективно структурировано хранение
> (наверно, какая-то реляционная организация) -- не забывай, что они
> поддерживают расширение xquery для insert, update, delete.
Наверное, или точно знаешь, что эти операции эффективны?
> интересно, это просто довольно примитивная примочка к существующей БД.
Так прикол в том, что база уже не чисто реляционной должна получаться.
> вроде там специальный бинарный формат, и для структурированного xml
> со схемой, там как-то эффективно структурировано хранение
> (наверно, какая-то реляционная организация) -- не забывай, что они
> поддерживают расширение xquery для insert, update, delete.
Наверное, или точно знаешь, что эти операции эффективны?
Можно создать аналог кластерного индекса.
Думаю, что при такой организации хранения xml с insert, delete, update дела обстоят очень хорошо.
The primary XML index is a shredded and persisted representation of the XML BLOBs in the xml data type column. For each XML binary large object (BLOB) in the column, the index creates several rows of data. The number of rows in the index is approximately equal to the number of nodes in the XML binary large object.
Each row stores the following node information:
* Tag name such as an element or attribute name.
* Node value.
* Node type such as an element node, attribute node, or text node.
* Document order information, represented by an internal node identifier.
* Path from each node to the root of the XML tree. This column is searched for path expressions in the query.
* Primary key of the base table. The primary key of the base table is duplicated in the primary XML index for back join with the base table, and the maximum number of columns in primary key of the based table is limited to 15.
This node information is used to evaluate and construct XML results for a specified query. For optimization purposes, the tag name and the node type information are encoded as integer values, and the Path column uses the same encoding. Also, paths are stored in reverse order to allow matching paths when only the path suffix is known.
Думаю, что при такой организации хранения xml с insert, delete, update дела обстоят очень хорошо.
> * Path from each node to the root of the XML tree. This column is searched for path expressions in the query.
Ох.
Может оно конечно и полезно кому-то, но не впечатляет ни разу.
Ох.
For each XML binary large object (BLOB) in the column, the index creates several rows of data. The number of rows in the index is approximately equal to the number of nodes in the XML binary large object.Получается, на каждую ячейку хранится по мини-xml-базе, которая таким вот не очень эффективным способом переводится в реляционное представление. Взамопроникновения реляционной и xml-моделей не наблюдается. Простой хак для об-xml-ивания реляционных данных, короче.
Может оно конечно и полезно кому-то, но не впечатляет ни разу.
Получается, на каждую ячейку хранится по мини-xml-базеЯ бы сказал, что это не очень адекватное описание.
которая таким вот не очень эффективным способом переводится в реляционное представление
а какой способ будет эффективным?
Взамопроникновения реляционной и xml-моделей не наблюдается.
Что ты под этим подразумеваешь? ИМХО как раз есть, как на уровне запросов, так и на уровне модели данных (xml погружается в реляционную с помощью специального типа -- естественное погружение). На уровне реализации все зависит от того как ты хочешь с этим работать, идеальных решений не бывает, которые работают на все случаи жизни. для случая неструктурированного xml (на сколько я понял).
> Я бы сказал, что это не очень адекватное описание.
В чём неадекватность? Ясно сказано, что xml - это специальный тип, и документы раскиданы по ячейкам (хотя и имеют внутреннюю структуру).
> а какой способ будет эффективным?
Уж ясно не тот, который приводит к квадратичному увеличению объёма хранимых данных, с соответственным замедлением как минимум операций обновления.
> (xml погружается в реляционную с помощью специального типа --
> естественное погружение)
Должно быть скорее наоборот - так как xml-модель более общая.
И с данными внутри xml - документа можно общаться по sql? Если нет, то это как раз и показывает полное отделение моделей.
В чём неадекватность? Ясно сказано, что xml - это специальный тип, и документы раскиданы по ячейкам (хотя и имеют внутреннюю структуру).
> а какой способ будет эффективным?
Уж ясно не тот, который приводит к квадратичному увеличению объёма хранимых данных, с соответственным замедлением как минимум операций обновления.
> (xml погружается в реляционную с помощью специального типа --
> естественное погружение)
Должно быть скорее наоборот - так как xml-модель более общая.
И с данными внутри xml - документа можно общаться по sql? Если нет, то это как раз и показывает полное отделение моделей.
немного по теме.
отсюда
отсюда
Impedance mismatch
Или точнее “Object-relational impedance mismatch” - это понятие, которое описывает тот факт, что объектно-ориентированное моделирование и реляционное моделирование построены на разных принципах, и когда когда их приходится совмещать, это не всегда происходит гладко.
не по теме
про объекты я не говорил ничего
про объекты я не говорил ничего
В чём неадекватность? Ясно сказано, что xml - это специальный тип, и документы раскиданы по ячейкам (хотя и имеют внутреннюю структуру).Если ты только хочешь грузить xml целиком, что довольно распространенная задача, то такая реализация самая эффективная. В случае xml индекса все узлы из всех колонок свалены в одну таблицу.
Уж ясно не тот, который приводит к квадратичному увеличению объёма хранимых данных, с соответственным замедлением как минимум операций обновления.Это ты про "Path from each node to the root of the XML tree"? Не думаю, что там так сильно квадратичное увеличение получается. Может и не так плохо, как плата за более эффективное выполнение запросов, когда условие на путь от корня не самое селективное условие, и нужно сначала искать узлы, удовлетворяющие другому условию (e.g. @name='John')
Должно быть скорее наоборот - так как xml-модель более общая.Так ты и общаешься с помощью sql + специальные методы. Возможно, что задача все погрузить в xml не стоит совсем. Есть большой опыт с реляционного моделью, каждая собака знает SQL, есть сложившийся API. Сегодня появляется xml, появляются какие задачи по хранению и работе с ним, все это и приводит к расширению поддержки со стороны БД.
И с данными внутри xml - документа можно общаться по sql? Если нет, то это как раз и показывает полное отделение моделей.
Короче в ms sql 2005 два подхода: через xml тип и через xml представления (над реляционными данными). В BOL расписаны задачи, которые решает каждый подход. Возможно использование гибридного подхода. Дальше можно говорить: покрываются твои задачи или нет. А просто рассуждать на абстрактном уровне в стиле: xml более общая модель, в нее и нужно все погружать -- можно, но не эффективно, скорее всего ты получишь решение, которые не отвечает существующим задачам сегодня.
Про реализацию тоже сложно говорить. В BOL, кроме того что запостил, не нашел ничего по реализации xml. Ну опять нужно брать конкретную задачу, рассматривать что предлагает ms sql, и смотреть на сколько его вариант эффективный.
ты хочешь сказать что XML модель не эквивалентна объектной модели?
обычно от XML хотят логичной объекности.
обычно от XML хотят логичной объекности.
в общем случае нет, разве это не очевидно?
если дерево высокое, то будет квадратичнре увеличение объёма
а если в схеме есть ограничение на высоту, тогда это по сути реляционные данные, и xml не нужен
а если в схеме есть ограничение на высоту, тогда это по сути реляционные данные, и xml не нужен
Какие способы существуют?Все зависит от того, как выглядят логи. Есть вариант использовать openxml (есть в 2000 и работать как с таблицей. Тогда можно сделать простенький джоб на основе следующего куска кода из BOL:
Понятно, можно просто заливать файл в nvarchar колонку.
Интересует поддержка native хранения xml в sql server 2000-2005
Какие существуют механизмы, способы доступа, языки запросов, эффективность хранения\скорость.
А также, какие существуют у SQL сервака механизмы автоматического сбора данных?
Скажем, моя прога выкладывает в папке XML логи, а сервер их забирает с некоторой периодичностью.
Заранее спасибо
declare @idoc int
declare @doc varchar(1000)
set @doc ='
<ROOT>
<Customers CustomerID="VINET" ContactName="Paul Henriot">
<Orders CustomerID="VINET" EmployeeID="5" OrderDate=
"1996-07-04T00:00:00">
<Order_x0020_Details OrderID="10248" ProductID="11" Quantity="12"/>
<Order_x0020_Details OrderID="10248" ProductID="42" Quantity="10"/>
</Orders>
</Customers>
<Customers CustomerID="LILAS" ContactName="Carlos Gonzlez">
<Orders CustomerID="LILAS" EmployeeID="3" OrderDate=
"1996-08-16T00:00:00">
<Order_x0020_Details OrderID="10283" ProductID="72" Quantity="3"/>
</Orders>
</Customers>
</ROOT>'
--Create an internal representation of the XML document.
exec sp_xml_preparedocument @idoc OUTPUT, @doc
-- SELECT statement using OPENXML rowset provider
SELECT *
FROM OPENXML (@idoc, '/ROOT/Customers')
EXEC sp_xml_removedocument @idoc
Оставить комментарий
amarcord74
Какие способы существуют?Понятно, можно просто заливать файл в nvarchar колонку.
Интересует поддержка native хранения xml в sql server 2000-2005
Какие существуют механизмы, способы доступа, языки запросов, эффективность хранения\скорость.
А также, какие существуют у SQL сервака механизмы автоматического сбора данных?
Скажем, моя прога выкладывает в папке XML логи, а сервер их забирает с некоторой периодичностью.
Заранее спасибо