Использование XML в большой БД

Yarik Voronov

Новичок
Re: Использование XML в большой БД

Автор оригинала: orka
Ситуация такая - готовится проект, который будет работать с большой БД, в которой будут храниться объекты с разными атрибутами.
Мало того, что эти объекты хранятся в таком виде, к тому же будут часто добавляться новые со своими уникальными полями, пересекающимися с некоторыми существующими.

Вопрос следующий - как лучше хранить такие данные? Мне кажется, что использование БД будет здесь неуместно. Если применять XML - то какие нюансы стоит сразу предусмотреть? Как лучше работать с такими данными?
Все зависит от того какие задачи ты хочешь поставить пред базой данных. Например: если новые уникальные поля не используютя широко и повсеместно в ввыборке, то их можно занести в отдельное поле скажем
additional_discription: "цветэтикетки=зеленый;бутылка=фигурная;крышка=обычная". Среди таких данных можно искать оператором SELECT ... WHERE additional_discription = LIKE(); (MySQL) или разбивать explode в РНР и т.д.

Ежели ты собираешься очень часто использовать уникальные поля и таких объектов ОЧЕНЬ много и их можно типизировать, то приемлемый вариант - это создать для них отдельные таблицы в БД. То есть своего рода предусмотреть класс для хранения уникальной информации каждого типа объектов. Ежели ТИПОВ объектов более 10 и в каждом типе более 100 объектов (хотя я еще такого не встречал :)), то просче всего расширить права администратора БД и создавать соответствующие таблицы.

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

С уважением
 

monah

Новичок
Я сейчас разрабатываю подобную базу данных.
Использование тестовых файлов, пусть и в формате XML, для больших баз, имхо не правильно.
Возможный вариант - использовать SQL базу для хранения, т.е. описывать там node, element и пр. Я имел такой опыт, мне не очень понравилось.
В настоящий момент я решил делать следующим образом: разбить объекты на разнородные группы, скажем продукты, книги, машины и т.п. Для объектов каждой группы выделить общие и дополнительные свойства. Общие заносить в основную таблицу. Для дополнительных свойств - таблица описания свойств: id, название, тип, данные (для типов enum и list), умолчание. Значения дополнительных свойств храняться в таблице: id_объета, id_доп_свойства_значение (или название и использовать его как ключ). Соотв. на каждую группу по три таблицы + таблица описания самих групп (описание доп. свойст для всех групп, в принципе можно свести в одну таблицу). Описание свойст собственно используется для интерфейса, чтобы не вводить каждый раз название свойства и проверять данные.
Обмен информацией можно оформить как XML (я так и хочу сделать). Т.е. после выполнения запроса совать все в XML, а при поступлении данных, определять какие свойства к чему относятся и пихать в соотв. таблицы.
Ежели ТИПОВ объектов более 10 и в каждом типе более 100 объектов (хотя я еще такого не встречал :))
Оптовая база с товарами разного типа (от одежды до стиральных машин).
 

Alexandre

PHPПенсионер
MySQL 5.1 позволяет делать выборку/замену по XPath, хранение XML осуществляется в текстовом поле
MsSQL 2005 - по мимо выборки по XPath, хранит XML данные в бинарном виде (тип XML), что значительно увеличивает время выборки.

недавно я написал UDF функцию xpath() для MySQL 5.0, оказывыается это все уже реализованно в 5.1 (но у меня установлен 5.0)

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

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

По структуре данных, у меня есть объекты, которые имеют свойства.
Часть свойств - имеют постоянный характер (как поля таблицы), а часть свойств хранятся как XML
 
Сверху