powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Другие СУБД [игнор отключен] [закрыт для гостей] / Оптимизация запроса
19 сообщений из 44, страница 2 из 2
Оптимизация запроса
    #38937096
Dimitry SibiryakovВо-первых, повторяю медленно: имеет смысл хранить только один базовый остаток. Если
изменяется документ раньше него, то триггер автоматически этот остаток скорректирует на
изменившуюся сумму. Поскольку задним числом документы проводятся редко, конкуренции и
связанных с ней проблем не будет.

Но даже если ты настаиваешь на хранении толпы остатков, то изменение пяти остатков это тот
же один запрос "update sklad set amount+:change where amount_date>:change_date". И
опять-таки операция редкая и риска нарваться на update conflict - нет.

Но повторю ещё раз: при хранении одного базового остатка, запрос получения остатка на
любую другую дату выливается в тривиальный и быстрый JOIN + GROUP BY.


Как я Вас понял должно быть организовано так:
1. Таблица "Остатки" - в которой хранятся только остатки на последние числа когда было движение, т.е.
код товара дата кол-во1 10.01.2015 1002 01.01.2015 503 20.01.2015 1504 30.01.2015 0
2. Таблица "Обороты" - в которой хранятся обороты по каждому товару, например
код документа код товара дата кол-во1001 2 01.01.2015 50 (приход на склад)1015 1 10.01.2015 100 (приход на склад)1100 3 20.01.2015 150 (приход на склад)1200 4 30.01.2015 -20 (расход со склада)1201 4 30.01.2015 -30 (расход со склада)1202 4 30.01.2015 -10 (расход со склада)
3. Ну и для того чтобы высчитать остатки например на текущую дату, в большинстве случаев будет достаточно взять просто информацию из таблицы "Остатки".
3. А если например надо взять остатки на 15.01.2015, то нужно выбрать записи из таблицы "Остатки" +/- количество из оборота...

Примерно так?
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937101
По поводу самого SQL-запроса. Там нечего переделывать? Он написан самое оптимально в текущей ситуации?
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937115
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей РябенкоПо поводу самого SQL-запроса. Там нечего переделывать? Он написан
самое оптимально в текущей ситуации?
Нет, запрос по-прежнему трёхэтажное дерьмо, которое даже теоретически не может работать
быстро.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937137
Dimitry SibiryakovАндрей РябенкоПо поводу самого SQL-запроса. Там нечего переделывать? Он написан
самое оптимально в текущей ситуации?
Нет, запрос по-прежнему трёхэтажное дерьмо, которое даже теоретически не может работать
быстро.

Подскажите пожалуйста, что в нем переделать? Меня это очень интересует.
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937140
Dimitry SibiryakovНет, запрос по-прежнему трёхэтажное дерьмо, которое даже теоретически не может работать
быстро.

Ну дерьмо или нет, но работает он сейчас в приложении за время равное 2,60-2,70 сек.
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937153
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей РябенкоПодскажите пожалуйста, что в нем переделать?
Выкинуть derived tables, использовать подзапрос с FIRST + ORDER BY.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937166
miwaonline
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей РябенкоDimitry SibiryakovНет, запрос по-прежнему трёхэтажное дерьмо, которое даже теоретически не может работать
быстро.

Ну дерьмо или нет, но работает он сейчас в приложении за время равное 2,60-2,70 сек.

Сколько у тебя наименований обсчитывается за это время? Сразу скажу, если меньше 100-200К (а скорее всего так и есть), то придется таки признать правоту Дмитрия, нравится это или нет. Он, кстати, очень скромный и отзывчивый человек, просто всячески пытается это скрыть :) Например, скромно не упомянул свой же топик- рецепт где детально расписывается как избежать таких проблем, как у тебя.
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937179
Я очень ценю помощь всех, кто помагает.
А рецепт почитаю. Спасибо :)
Кол-во записей в таблице SprTovar 5000, в таблице Sklad 300000

В общем, если дату не выбирать, то запрос получается такой.
Код: sql
1.
2.
3.
4.
5.
6.
7.
select a.*, 
    (SELECT top 1 S.Kol 
       FROM Sklad S 
       WHERE S.KodSklad=0 AND S.KodTov=a.KOD AND S.DATA<='15.04.2015'
       ORDER BY S.DATA DESC) as Ostatok 
  FROM SprTovar a 
  order by lower(a.Name)


В приложении выборка выполняется по времени от 1,00 до 1,20 сек. Что почти приемлемо. В идеале было бы отлично, если бы время занимало не более 0,5сек.

Если выбирать с датой, то запрос получился такой:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
select a.*, 
    (SELECT top 1 S.Kol 
       FROM Sklad S 
       WHERE S.KodSklad=0 AND S.KodTov=a.KOD AND S.DATA<='15.04.2015'
       ORDER BY S.DATA DESC) as Ostatok, 
    (SELECT top 1 S.DATA 
       FROM Sklad S 
       WHERE S.KodSklad=0 AND S.KodTov=a.KOD AND S.DATA<='15.04.2015'
       ORDER BY S.DATA DESC) as DATA 
  FROM SprTovar a 
  order by lower(a.Name)

И время выполнения его в приложении равняется от 2,00 до 2,20 сек.

Нельзя ли в одном подзапросе выбрать и дату и количество? Подскажите, а то не получается.
Если пробовать так:
Код: sql
1.
2.
3.
4.
5.
6.
7.
select a.*, 
    (SELECT top 1 S.Kol, S.Data 
       FROM Sklad S 
       WHERE S.KodSklad=0 AND S.KodTov=a.KOD AND S.DATA<='15.04.2015'
       ORDER BY S.DATA DESC) 
  FROM SprTovar a 
  order by lower(a.Name)


то пишет ошибку:
poQuery: Error 7200: AQE Error: State = S0000; NativeError = 2166; [iAnywhere Solutions][Advantage SQL Engine]SELECT sub-query returns more than one column.
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937184
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miwaonlineдетально расписывается как избежать таких проблем, как у тебя.
Нет, это рецепт на совсем другие проблемы. Хотя его можно применить и к этой.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937223
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Рябенкоприложении выборка выполняется по времени от 1,00 до 1,20 сек. Что
почти приемлемо. В идеале было бы отлично, если бы время занимало не более 0,5сек.
Убери ORDER BY lower().
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937238
Dimitry SibiryakovУбери ORDER BY lower().


Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
select a.*, 
   (select Top 1 b.Kol as Kol from Sklad b 
                    where a.Kod=b.KodTov 
                      and b.Data<='15.04.2015'
                      and b.KodSklad=0 
                      order by b.Data desc 
                      ) as Ostatok 
from SprTovar a 
where a.PriznDel=False and a.Kod_G IN (select Kod from SprGTovar where Kod_R<>2) 
order by lower(a.Name)



Если с order by, то время
1,122882 сек.
1,119102 сек.
1,115236 сек.
1,116101 сек.

Если вообще без order by
1,106597 сек.
1,100133 сек.
1,102141 сек.
1,099016 сек.
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937255
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovВо-первых, повторяю медленно: имеет смысл хранить только один базовый остаток.Есть оперативна работа с текущим остатком и отчеты на число Х, или на период от "забора" до "обеда". Остатки им нужны в общем случае разные.

Dimitry SibiryakovНо повторю ещё раз: при хранении одного базового остатка, запрос получения остатка на любую другую дату выливается в тривиальный и быстрый JOIN + GROUP BY.быстрым он может быть только если оборотов по товару не много. (естественно подразумевается, что запрос не хреначит натуралом)
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937258
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей РябенкоПо поводу самого SQL-запроса. Там нечего переделывать? Он написан самое оптимально в текущей ситуации?Я уже написал выше, что получение остатка по товару на дату Д надо обернуть хранимой процедурой, селективной, которая и будет отдавать наружу чиселку.
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937259
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
where a.PriznDel=False and a.Kod_G IN (select Kod from SprGTovar where Kod_R<>2)

В топку.
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937260
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
хм. А откуда в запросе TOP взялся? Какой сервер?
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937263
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Рябенко1. Таблица "Остатки" - в которой хранятся только остатки на последние числа когда было движение, т.е.когда потребуется собрать оборотку за год и столкнуть ее с предыдущем годом, для каких либо интересов начальства одно остатка будет маловато, рубать ей придется ой как долго.

Андрей Рябенко2. Таблица "Обороты" - в которой хранятся обороты по каждому товару, напримерНа кой вообще эта таблица, если все можно взять из таблиц первичных документов?
Если в первичке будет в одной таблице товар, дата и контрагент и композитный индекс по этим параметрам то предагрегированная таблица оборотов не нужна.
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937267
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисTOP взялся? Какой сервер?если не файрберд, то с селективными хп ждет облом.
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937274
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей РябенкоpoQuery: Error 7200: AQE Error: State = S0000; NativeError = 2166; [iAnywhere Solutions][Advantage SQL Engine]SELECT sub-query returns more than one column.

Судя вот по этому Sybase ASE. Так ты не в той ветке спрашиваешь. По оптимизации структуры здешние советы конечно подойдут, а вот про оптимизацию запроса лучше в родной ветке спрашивать.
...
Рейтинг: 0 / 0
Оптимизация запроса
    #38937276
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan_Pisarevskyбыстрым он может быть только если оборотов по товару не много.
Да, с маленьким уточнением: оборотов между базовой датой и требуемой. Поэтому базовую дату
надо двигать аккуратно, но регулярно так, чтобы она была в матожидании требуемой даты.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
19 сообщений из 44, страница 2 из 2
Форумы / Другие СУБД [игнор отключен] [закрыт для гостей] / Оптимизация запроса
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]