1sqlite долго выполняется запрос по остаткам #544568

Уважаемые знатоки! Поделитесь пожалуйста знаниями - почему такой запрос выполняется около 160 секунд при dbf-базе и 4-х активных пользователях в ней: Конфа самописная. Быстрой обработки движений в регистре нет. В регистре два ресурса - количество и сумма и три измерения - склад, номенклатура и серийник. Где можно попробовать поискать?

А ничего, что он радугу кажет ?

Почему? Когда один в базе - выводит остатки по серийникам.

Кажеццо странным, что фильтры по списку номенклатуры и складу ставятся только на движения Зачем во вложенных запросах склад если его нет в группировке?

Склад нужен чтобы фильтр поставить. А если фильтр воткнуть во всех запросах - то будет быстрее?

"Быстрой обработки движений в регистре нет." - тебе шо, трудно добавить?

А правда, в остатках нет вообще фильтра :D

По запросу итогов нет фильтра. Если на измерении Товар стоит отбор итогов, лучше иннерджойнить табличку с товаром к итогам. Если на измерении Товар стоит отбор движений, лучше иннерджойнить табличку с товаром к движениям. "HAVING SUM(Количество) > 0" - смело. Уверен, что нет отрицательных остатков? Ну и желательно смотреть, что вываливается при включенной отладке. Еще полезно добавить в начало запроса explain query plan и посмотреть что выдаст.

а вот здесь: разве не надо писать Sum(Количество) чтобы Group by работал

см. всё, что ниже.. :)

Учел критику в меру скудоумия. Сейчас вариант такой: Ну, соответственно, включил в регистре остатков быструю обработку движений. Пара вопросов: 1. Есть ли ещё что улучшить в запросе или можно этот окончательный вариант заливать в базу и мерить производительность? 2. Откуда выдрать прямым запросом остатки на ТА - они ИМХО где-то должны в виде отдельной таблицы храниться или нет? (Просто запрос вызывается при проведении документа и, поскольку очень часто остатки совпадают с ТА, то каждый раз строить движения за месяц, как мне кажется, несколько глупо.)

объясните плиз мне неспециалисту, зачем в запросе . ТекЗапрос=" |SELECT . два селекта??? . во вложенном селекте - что, в итогах по регистру может быть нескольо записей по одному серийнику ...???

На мой взгляд, по двум причинам: 1. Чтобы проверять задвоившиеся/отрицательные записи в регистре (мало ли у кого как руки дошли - я не господь бог, а совершенную защиту от дурака, даже ему, наверное, сделать не под силу) 2. Если убрать начальный селект и в селекте по итогам регистра поставить sum(Количество) и sum(Сумма) - то он просуммирует их с таблицей по движениям? Иными словами, оператор union all позволяет суммирование всех результатов? Я, честно говоря, не знаю, поэтому смиренно надеюсь на помощь опытных в скуле товарищей.

Предыдущее сообщение относилось к

Ап

а почему сразу не написать.. . select |  Номенклатура, . ???

Так он к этому количество и сумму из таблицы движений присуммирует?

Попробовал убрать "внешний" SELECT. Стали некоректно считаться суммы по нештучным товарам - то есть по тем товарам по которым нет серийников.

Апну что ли.

не помогло

Ап не помог

Зачем убирать внешний селект? Все нормально, только малость подправить (можно убрать склад из вложенных запросов, из селектов) Откуда выдрать прямым запросом остатки на ТА - они ИМХО где-то должны в виде отдельной таблицы храниться или нет? Выдрать из таблицы итогов А если тупо установить фильтр (если итоги не актуальны - временный расчет) и выгрузить итоги? Интересно какая разница во времени

1. То есть я правильно понял что на начало месяца в итогах лежит на самом деле то что на ТА? 2. С разницей по времени как-то непонятно: - Когда запускаю один базу - разница о времени раз в 10 - запрос быстрее - т.е. 0,3 секунды при расчете регистра и 0,03 секунды при прямом запросе. - Когда в базе сидят три человека - прямой запрос выполняется ок. 160 секунд(!). Расчет регистра даже не запускал ибо страшно сколько времени может уйти. Итого - непонятно почему такая разница во времени между тем когда я один и тем когда в базе ещё есть люди. НО. Это всё было на первоначальном варианте запроса. Новый вариант только залил в базу и не проверял. В течении недели отпишусь по результатам с замерами.

фокс обгонит 1sqlite для этого запроса в разы, если что.

для остатков на ТА, присоединять табличку движений не надо, нужно сего лишь взять строчки из таблички итогов на блежайшую дату периода хранения останков.

а так, запрос у тебя не верный. Вот это бред.

Нужно началоМесяца, а не конец, это раз Нужно пользовать ПолучитьНачПериода объекта MetaDataWork для получения границ периода, ибо если периодичность хранения останков <> месяц, то твой запрос коту под хвост

+26 это два.

Ну и конечно лучше использовать класс ПрямойЗапрос. Там все уже написано до нас. И грамотно написано.

ну.. не факт. Если важна скорость, то для дбф лучше фокс всё же. На больших табличках 1sqlite проигрывает, причем значительно.

+29 на некоторых запросах,естесственно.

Тогда вопрос - я правильно понимаю, что фокс придется ставить на каждую тачку работающую с этой базой?

Мне скорость огого как критична. У меня люди с SQL версии на dbf легализовались. Они к тормозам не привыкли...

да не фокс , а всего лишь драйвер

+33 и скульлайт проигрывает на group by

в остальном, работать с ним приятнее. ЗЫ: для фокса нужно уметь писать запросы с попаданием в индекс, а вот 1sqlite сам их строит автоматом.

А тебе, для начала, нужно свой запрос исправить, с учетом .

да я драйвер и имел в виду. Хмм. Попробуем обойтись, для начала, без этого. Где почитать про попадания в индекс?