В теме одно сообщение

[ogx-group]

Здравствуйте.

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

Собственно, вопрос: возникла идея апдейтить напрямую в БД сиквельным запросиком, что намного проще и быстрее, как нам кажется. Полезли в базу, обнаружили, что каждому поля в типе элемента соответствует 3 поля в БД с приписками _n, _d, _s. Посмотрели на цену и предположили, что это число, текст и дата, вроде (точно не помню, не суть важно). Используются для цены 2: _n, _s. Проапдейтили это счастье в обеих полях, система не увидела, а при переиндексации базы и вовсе обнулила. 

Что мы не учли и не поняли?) Посоветуйте, как правильно работать с элементами в БД?

 

Заранее спасибо.

[SmetDenis]

Прошу прощения за долгий ответ.

 

Изначальный способ хранения в Zoo не дат делать поисковые запросы  в базу данных.

"Индексация" обрабатывает и складывает информацию в более удобном варианте.

 _n, _d, _s.  - это постфиксы  для разных типов данных (числовой, дата и строкой).

Если данные подходят под формат, то они конвертируются и отправляются в нужную ячейку. Затем можно искать по диапозону с помощью SQL запросов.

 

Поле цены имеет особый вариант хранения, в силу того что там есть такие доп поля как остатки, артикулы итд.

Это все хранится в #__zoo_jbzoo_sku, где каждая строка  - это отдельная вариация цены.

 

При переиндексации  все индексные таблицы удаляются через DROP TABLE

И создаются снова. Такой грубый метод позволяет решить две трудности

 - Актуальный набор столбцов.

 - Оптимизация хранения данных и индекса для всей таблицы.

 

Создание таблиц происходит в хелпере jbtable.php

Логика переиндексации находится в модели searchindex

Данные для индексации цены формируются в элементе цены jbpriceadvance

 

Наиболее рекомендованный способ, на мой взгляд - использовать API

http://forum.jbzoo.c...zy-dannyh-dlya/