Речь о каталоге товаров. Каталог загружается на сервер в виде 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х таблиц, например?), и указать на то, что я, возможно, упускаю из вида, ошибки логики.
Средний
Простой
