VicTHOR
@VicTHOR
(╮°-°)╮┳━━┳ ( ╯°□°)╯ ┻━━┻

База данных или xml?

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

Было предложено хранить данные каталога всего в 2-х таблицах, как я понимаю, в виде
id | product_xml_id | xmlNodeName
xmlNodeName_id | Value

Или как-то не так, если кто-то знает вариант 2х таблиц, поправьте.
Как я понимаю, в таком случае множественное свойство "цвет" каждого товара должно иметь уникальный идентификатор в xml.

Так же можно хранить в одной таблице, вытягивая в одну строку
id | product_xml_id | xml
При этом, строя каталог, достать всё, а потом нужное достать через xPath.

Или стандартно распарсить xml и построить таблицы для товара
id | product_xml_id | property1 | property2
id | product_id | colors 
id | colors_id | sizes


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

Итого 4 варианта.
На сколько будут актуальны индексы в первых 2х?
В любом из случаев нужно кэширование, т.е. данные возьмутся один раз, а следующий раз будет при обновлении xml.
xml надо обновлять. В случае большого файла, полагаю, это может быть долго (по крайней мере 1с может долго его строить), что нежелательно. Но можно выгружать части и делать апдейт БД (в каждом ли из первых 2 случаев это корректно?).
Кэширование вижу так: один раз строится страница, ответ дублируется в новый файл, в начале страницы проверка существования этого файла, если есть - вывести его. После обновления xml удалять файл. В закэшируемом файле будет корректный last-modified.
При этом будут не кэшируемые странцы (например, фильтр - показать товары 2-х производителей 1-го размера 2-х цветов).

Мне нужно осознать нюансы разных вариантов, минусы, оптимизацию (что быстрее - прочесть xml или сделать выборку из 3х таблиц, например?), и указать на то, что я, возможно, упускаю из вида, ошибки логики.
  • Вопрос задан
  • 378 просмотров
Решения вопроса 2
Adamos
@Adamos
Нет никаких вариантов. XML - это удобный формат для обмена информацией между принципиально разными системами (как 1С и сайт, например). На этом его достоинства заканчиваются, и больше его нигде использовать нет смысла.
Как только речь заходит о постоянной обработке данных и скорости этой обработки - естественно, логично это делать при помощи баз данных, специально для этого придуманных и давно отполированных лучше, чем любые ваши велосипеды.
Ответ написан
@mamontm
Идеальный вариант - комбинированный:

Медленно, но удобно и универсально - схема EAV (удобнее для частичного обновления)
А для быстрой отдачи другой способ - СУБД типа Full-Text-Search

Мне нужно осознать нюансы разных вариантов, минусы, оптимизацию (что быстрее - прочесть xml или сделать выборку из 3х БД, например?)

Почему из трех БД?
Из 3-х таблиц одной БД. Конечно из БД быстрее.

Но! Если вы разово загрузите в оперативную память из XML, построите нужную структуру и ваша серверная часть не будет перезапускаться - то из XML (в оперативной памяти) будет быстрее.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
profesor08
@profesor08
Все это фигня, по производительности и качеству, ничто не сравнится с .txt файлом. У тебя в руках будет все, полный контроль над любыми действиями. Оно того стоит, чуть заморочиться над обработкой, зато какой профит. Все реляционные бд просто будут курить в сторонке.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы