Даны справочник товаров, свойства товаров и цены товаров, остаток утром, проданно:
1.
2.
3.
create table TOVARY(id integer,kod char(20),name char (120))PRIMARY KEY (id);
create table TOVARY_sv(id integer,kod char(20),name_sv chare (120),znach char(12)) PRIMARY KEY (id);
create table chena(id integer,kod char(20),chena numeric(9,2));
Причем на один товар может быть несколько свойств, так и не одного:
таблица TOVARY
1.
2.
3.
id kod name
1 12 Штука
2 45 Фиговина
3 123 Что-то
Таблица TOVARY_sv
1.
2.
3.
id kod name_sv znach
1 12 Цвет 20_БУКОВ Синий 20БУКОВ</const>ЕЩЕ_КУЧА_БУКОВ
2 12 Вес 20_БУКОВ Тяжолый 20БУКОВ</const>ЕЩЕ_КУЧА_БУКОВ
3 123 Цвет 20_БУКОВ Красный 20БУКОВ</const>ЕЩЕ_КУЧА_БУКОВ
Ну и цены: один товар - одна цена.
"Вяжу" их:
1.
2.
3.
4.
5.
6.
7.
8.
9.
select tii.kod as KOD_TOVARA,tii.`name` as NAZVANIE,
TRIM(MID(tiip.`znach `,20,locate("</const>",tiip.`znach `)-20)) as CVET,
TRIM(MID(tiip1.`znach `,20,locate("</const>",tiip1.`znach `)-20)) as VES
from TOVARY tii
left join TOVARY_sv tiip on (tiip.`kod`=tii.`kod`)
left join TOVARY_sv tiip1 on (tiip1.`kod`=tii.`kod`)
where tii.name like "%ЧТО-ТО%"
and tiip.`name_sv` like "%ЦВЕТ%"
and tiip1.`name_sv` like "%ВЕС%" limit 100
На тестовых табличках все летает со свистом!
Но на реальной БД (TOVARY - более 17 тыс записей, TOVARY_sv -34 с гаком) - время выполнения запроса более минуты. И это я еще не подцепил цены и остатки :-(
Вопрос:
ковырять запрос для его оптимизации? если да - то в каком направлении
или сделать в своем приложении кнопочку "обновить справочник" которую буду нажимать и будет создаваться табличка в которой вся инфа (кроме остатков) сведена в одну "плоскую" таблицу вида:
и вязать эту таблицу с таблицами остатков?
З.Ы. Аналогичная по функционалу программа писана на фоксе, работает за доли секунды, но это после того как эту БД обработал "конвертер данных". Недостатки: дрневняя как .... мамонта, нет исходников, под линем работает с "бубном", да и надо добавить функционала. Проще переписать заново...
