Магазин на PHP + XML + MySQL. Поиск товаров?

[Angel Echo]

Магазин на PHP + XML + MySQL. Поиск товаров?

Имеется магазин такой конфигурации:

1. База данных:

Таблица товаров
Article (articleId int, articleDescription text);

Таблица страниц каталога
Catalogue (catId int, catContent text);

Таблица для связки товаров и каталога
ArticleCatalogue (articleId int, catId int);

В поле articleDescription хранится XML с описанием товара (набор параметров со значениями, текстовое описание, список ссылок на картинки и проч.), а в поле catContent - XML с описанием страницы каталога (текст, картинки, ссылки).

2. В файле menu.xml хранится дерево меню вида

<MENU>
<ITEM id="1"/>
<ITEM id="2">
<ITEM id="3"/>
</ITEM>
</MENU>

где id соответствует полю catId в таблице Catalogue

3. Для отображения страницы каталога id генерируется XML следующего вида:

<PAGE> + menu.xml + catContent + articleDescription(соответствующие каталогу)</PAGE>

Вопрос: как лучше организовать поиск товаров в каталоге?

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

 

[BeGe]

зря
как ты будешь искать товар по каким-то параметрам

Вызывает опасение не достаточность информации в области проектированная приложений.

 

[slach]

то как ты сделал, совершенно не годится для MySQL
в нем нет никакой нормальной поддержки XPath на сегодня
а то, что планируется не будет имель должной производительности

разбивай структуру, нормализуй ее...
а "сборные куски" articleDescription - кешируй

 

[Angel Echo]

Автор оригинала: BeGe
зря
как ты будешь искать товар по каким-то параметрам

[

C помощью XPath !!! Это весьма мощная и удобная штука. Например, имеется скрипт, который читает из БД 3000 записей товаров, генерирует из значений поля articleDescription один большой XML документ и выбирает из него узлы товаров по условию, что один из параметров (численный) больше 100 и является четным числом. Так вот время его выполнения составляет 2,5 секунды, причем 1,5 из них занимает вывод результатов через XSL (libxml2).

Вызывает опасение не достаточность информации в области проектированная приложений.

Поясни, что имелось в виду?

-~{}~ 05.07.05 21:26:

slach
Приведение БД к нормальным формам - это одно, а удобство хранения разнородных данных - совсем другое. В записи товара должны храниться и описание, и произвольное количество сопутствующих ссылок на изображения, да и параметров у каждого товара может быть любое количество любых, вот например цена может быть: для физ. лиц, для юр. лиц, со скидкой, оптовая и проч. что ж для каждой цены отдельное поле заводить??? А вот в XML все просто:
<PRICES>
<PRICE type="discount">100</PRICE>
<PRICE type="natural">120</PRICE>
<PRICE type="juridical">140</PRICE>
</PRICES>
Кстати, XML удобен во всем кроме поиска, и в редактировании данных, и в хранении, а уж про отображение и говорить нечего. Единственное, что вызывает проблемы - это поиск

 

[[DAN]]

Angel Echo, XPath - это хорошо. Но, как сказал slach, в наиболее популярных СУБД поддержка этого языка слабовата.
Генерация XML из всех данных БД - очень дорогая операция. От нее стОит сразу отказаться.

Я вижу как минимум три решения:
1) Выносить все ключевые поля в отдельную таблицу, делать по ней индексы и шерстить в поиске нужных данных. Избыточность данных компенсируется удобством их поиска и скоростью этого поиска.
2) Т.к. описание товаров и страниц каталога хранятся в текстовом поле, можно делать поиск прямо по нему с условием LIKE.
Например, "WHERE articleDescription LIKE '%<PRICE>100</PRICE>%'"
Тут все зависит от количества записей и объема каждой записи. Вобщем, нужно тестировать.
3) Использовать стороннюю программу для индексации страниц сайта (mnogosearch, siteMETA etc.)

Есть еще один вариант - отказаться от XML ;-)

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

 

[Нечто]

myXTree
Беда только, что nested sets (тяжелое обновление) и запросов прилично.
Сейчас вот пишу репозиторий древовидный типа JSR-170 с экспортом в XML. На мой взгляд, это то, что нужно для такого рода задач, так что стоит подумать.

 

[Angel Echo]

[DAN]
Гм... Вариант 1 - это некое компромисное решение, т.е. хранить параметры, по которым осуществляется поиск в качестве полей БД, а всю остальную инфу сливать в XML ?
Эта идея в принципе подходит, но объем кода возрастет вдвое

Вариант 2 сразу отпадает, ведь как искать в таком случае искать на больше, меньше, а индексация подразумевает все тот же полнотекстовый поиск.

А вот почему стоит сразу отказаться от генерации XML из БД,
ведь время обработки XML из 3000 записей измеряется если быть точным 0,08 секундами + 0,02 секунды на выборку из БД. Так что, хоть производительность и мала, но удобство максимально для небольших магазинов, порядка десятков тысяч товарных позиций !

Интересно, как все это реализовано у известных магазинов, на Озоне, например, они дают на экспорт один громадный XML файл, даже структуру его приводят:
http://www.ozon.ru/context/detail/id/1150389/

 

[slach]

Angel Echo, складывается впечатление,что ты вообще не понимаешь о чем говоришь

причем тут экспорт в XML на озоне ???
к сведению ... для тебя этот БОЛЬШОЙ файл у них генерится из базы причем (какой сюрприз) из нормализованной базы =)

еще раз
1) все эти стоны по поводу "ах у меня произвольное кол-во картинок", "ах у меня произвольное кол-во характеристик товара", "ах, какая у меня будет сложная структура базы"
говорят только о том, что ты мало работал с SQL

2) ты XML articleDescription в данном случае потом после ВЫБОРКИ из SQL базы далее используешь ??? преобразовываешь в HTML через XSLT (xslt_* ф-ции)??? преобразовываешь в DOM и бегаешь по заданным узлам дерева самостоятельно ??? ( http://php.net/manual/en/ref.domxml.php ) ? работаешь с ним через SAX ?? (xml_* ф-ции)?

3) делай как тебе советуют, не парь мозг людям...
а именно
нормализованная база для каталога товара будет 10-12 таблиц максимум
при выборке ВСЕЙ инфы об одном товаре
можешь для большей производительности сгенерить XML подобный articleDecription и потом кешировать его хоть в базе хоть в файле с заданным таймаутом

поиск упростится довольно сильно
и как ни странно работать будет быстрее =)

либо переходи на Cache, Tamino, Virtuoso и юзай XML там =)

 

[Angel Echo]

С SQL я работаю уже 3 года! Прекрасно пониманию, что такое реляционные БД и их нормализация. А вот с XML опыт работы только около полугода. Основной его плюс, как мне кажется, - возможность хранения и редактирования элементарных фрагментов данных web-страницы в готовой для отображения форме без ущерба удобству их обновления, ну и разумеется удобный обмен данными между пользовательскими и серверными скриптами.
Вопрос в том, что вытаскивать из БД записи и генерировать из них XML-документы для вывода и наоборот, полученный от пользователя XML-документ разбивать и вытаскивать параметры соответствующие структуре таблиц - вот что мне кажется каким-то неоправданным переливанием из пустого в порожнее, поэтому хотелось бы услышать о том, какие решения существуют в проблеме совмещения технологий реляционных БД и XML, причем решения не архитектурные типа XML-ориентированных СУБД, а именно программные (оптимизация поиска, чтения/записи XML в БД и проч.) !

 

[lucas]

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

XML -- формат представления данных.

 

[maxim]

Господин *Slach* правильно говорит. А для всех твоих дополнительных параметров можно завести еще табличку(таблички) и объединять их в запросе. Именно так я и делаю в таблице товары у меня наиболее стандартные параметры. А все нестандартные вынесены в другую таблицу. Например цветовые варианты товара. А xml+xslt использую для преобразования в html, print version и просто для удобного создания дерева страницы.
Несколько сумбурно, но думаю Вы поймете.

 

[[DAN]]

> Эта идея в принципе подходит, но объем кода возрастет вдвое.
Откуда это "вдвое"? Правятся лишь sql-запросы на выборку, и всё.

 

[Angel Echo]

Откуда это "вдвое"? Правятся лишь sql-запросы на выборку, и всё.

Правятся еще и SQL-запросы на обновление + вычленение из XML, полученного от пользователя, нужных параметров для записи в поля БД.

XML -- формат представления данных.

А вот здесь можно поспорить! Для web-приложений XML содержит данные страницы, и если хранить их в таком виде, то XML - это формат хранения данных ! Например, в поле catContent содержится XML текста страницы. Такой вот, например, упрощенный вариант (заголовок, новости данной страницы, набор блоков текста с картинкой, комментарии пользователей к данной странице):

<PAGE id="1">
<HEADER>заголовок_страницы</HEADER>
<NEWS>
<NEWS date="дата">текст новости</NEW>
</NEWS>
<PARAGRAPH align="left">
<IMAGE src="адрес_картинки"/>
<TEXT color="black">текст</TEXT>
</PARAGRAPH>
<COMMENTS>
<ITEM date="дата" user="имя пользователя">текст</ITEM >
<ITEM date="дата" user="имя пользователя">текст</ITEM >
<COMMENTS>
</PAGE>

Выходит я храню в XML данные страницы !

-~{}~ 06.07.05 13:57:

Если для каждого элемента страницы заводить по таблице (а может и больше, если связи многие ко многим), то база данных будет содержать эдак пару сотен таблиц ?!!!

-~{}~ 06.07.05 14:00:

[DAN]
Пока я все же остановился на варианте с дубликатами данных в полях БД и XML. Т.е. цены, наименование, размеры, вес и проч. характеристики, свойственные всем товарам выношу в поля БД, а полное описание в XML.

 

[lucas]

1.

XML -- формат представления данных.

А вот здесь можно поспорить!

Формулирую для первоклассников: XML -- формат, предназначенный для осуществления представления данных.

2.

XML содержит данные страницы, и если хранить их в таком виде, то XML - это формат хранения данных !

Ага. Черепаха откладывает яйца, поэтому она -- курица.

Выходит я храню в XML данные страницы !

Ты их представляешь в ненормализованном виде.

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

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

 

[[DAN]]

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

Соответственно, методы и средства обработки структур данных различны.
Для РСУБД это SQL, для XML это XSLT, XPath, XLink etc.

Кстати, если уж ты говоришь о том, что

XML -- формат, предназначенный для осуществления представления данных.

то будь добр, уточняй, о каких данных идет речь. HTML тоже представляет данные.
HINT: rtfm "Document-Centric" vs. "Data-Centric"

В своем вопросе тов. Angel Echo пытается применить язык XPath к данным в РСУБД. Естесственно, это у него не получится.
Поэтому приходится приводить в соответствие структуру данных и методы ее обработки.
Т.е. либо
1) Формировать из данных XML-документ и применять к нему XPath-запросы
либо
2) Вычленять из XML-документа существенные данные и выносить их в отдельные поля таблицы (не помню как это по-научному называется). А уже затем применять к этим данным SQL-запросы.

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

 

[lucas]

[DAN]

1. Спасибо.

2. У умных дядь (http://www.w3.org/XML/):

Extensible Markup Language (XML) is a simple, very flexible text format derived from SGML (ISO 8879). Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere.

 

[Angel Echo]

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

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

Я бы не стал ставить под сомнение эффективность и удобство функций DOM в пятом PHP для обработки данных XML ! Единственный (!!!) недостаток XML - сложность поиска и выборки больших объемов информации. Да и XML-документ иногда напоминает что-то знакомое:

<TABLE name="">
<ROW id="1"><FIELD1></FIELD1><FIELD2></FIELD2></ROW>
<ROW id="2"><FIELD1></FIELD1><FIELD2></FIELD2></ROW>
</TABLE>

Вот только гибкость несравнима !

 

[lucas]

Свойства товаров -- отнудь не одна из "сложных вложенных структур данных".

 

[Angel Echo]

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

-~{}~ 06.07.05 15:04:

В полях таблиц БД удобно хранить, скажем данные пользователей, там действительно все очевидно, логин, пароль, Ф.И.О. и проч.

 

[Benderlio]

Angel Echo
а что мешает сделать таблицу с параметрами и соответственно таблицу со значениями параметров и продавайте себе и конфеты и х.з.