|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
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, то нужно выбрать записи из таблицы "Остатки" +/- количество из оборота... Примерно так? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 13:22 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
По поводу самого SQL-запроса. Там нечего переделывать? Он написан самое оптимально в текущей ситуации? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 13:26 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
Андрей РябенкоПо поводу самого SQL-запроса. Там нечего переделывать? Он написан самое оптимально в текущей ситуации? Нет, запрос по-прежнему трёхэтажное дерьмо, которое даже теоретически не может работать быстро. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 13:37 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovАндрей РябенкоПо поводу самого SQL-запроса. Там нечего переделывать? Он написан самое оптимально в текущей ситуации? Нет, запрос по-прежнему трёхэтажное дерьмо, которое даже теоретически не может работать быстро. Подскажите пожалуйста, что в нем переделать? Меня это очень интересует. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 13:48 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovНет, запрос по-прежнему трёхэтажное дерьмо, которое даже теоретически не может работать быстро. Ну дерьмо или нет, но работает он сейчас в приложении за время равное 2,60-2,70 сек. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 13:51 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
Андрей РябенкоПодскажите пожалуйста, что в нем переделать? Выкинуть derived tables, использовать подзапрос с FIRST + ORDER BY. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 14:01 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
Андрей РябенкоDimitry SibiryakovНет, запрос по-прежнему трёхэтажное дерьмо, которое даже теоретически не может работать быстро. Ну дерьмо или нет, но работает он сейчас в приложении за время равное 2,60-2,70 сек. Сколько у тебя наименований обсчитывается за это время? Сразу скажу, если меньше 100-200К (а скорее всего так и есть), то придется таки признать правоту Дмитрия, нравится это или нет. Он, кстати, очень скромный и отзывчивый человек, просто всячески пытается это скрыть :) Например, скромно не упомянул свой же топик- рецепт где детально расписывается как избежать таких проблем, как у тебя. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 14:08 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
Я очень ценю помощь всех, кто помагает. А рецепт почитаю. Спасибо :) Кол-во записей в таблице SprTovar 5000, в таблице Sklad 300000 В общем, если дату не выбирать, то запрос получается такой. Код: sql 1. 2. 3. 4. 5. 6. 7.
В приложении выборка выполняется по времени от 1,00 до 1,20 сек. Что почти приемлемо. В идеале было бы отлично, если бы время занимало не более 0,5сек. Если выбирать с датой, то запрос получился такой: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
И время выполнения его в приложении равняется от 2,00 до 2,20 сек. Нельзя ли в одном подзапросе выбрать и дату и количество? Подскажите, а то не получается. Если пробовать так: Код: sql 1. 2. 3. 4. 5. 6. 7.
то пишет ошибку: poQuery: Error 7200: AQE Error: State = S0000; NativeError = 2166; [iAnywhere Solutions][Advantage SQL Engine]SELECT sub-query returns more than one column. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 14:17 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
miwaonlineдетально расписывается как избежать таких проблем, как у тебя. Нет, это рецепт на совсем другие проблемы. Хотя его можно применить и к этой. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 14:20 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
Андрей Рябенкоприложении выборка выполняется по времени от 1,00 до 1,20 сек. Что почти приемлемо. В идеале было бы отлично, если бы время занимало не более 0,5сек. Убери ORDER BY lower(). Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 14:39 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovУбери ORDER BY lower(). Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Если с order by, то время 1,122882 сек. 1,119102 сек. 1,115236 сек. 1,116101 сек. Если вообще без order by 1,106597 сек. 1,100133 сек. 1,102141 сек. 1,099016 сек. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 14:48 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovВо-первых, повторяю медленно: имеет смысл хранить только один базовый остаток.Есть оперативна работа с текущим остатком и отчеты на число Х, или на период от "забора" до "обеда". Остатки им нужны в общем случае разные. Dimitry SibiryakovНо повторю ещё раз: при хранении одного базового остатка, запрос получения остатка на любую другую дату выливается в тривиальный и быстрый JOIN + GROUP BY.быстрым он может быть только если оборотов по товару не много. (естественно подразумевается, что запрос не хреначит натуралом) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 15:01 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
Андрей РябенкоПо поводу самого SQL-запроса. Там нечего переделывать? Он написан самое оптимально в текущей ситуации?Я уже написал выше, что получение остатка по товару на дату Д надо обернуть хранимой процедурой, селективной, которая и будет отдавать наружу чиселку. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 15:03 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
where a.PriznDel=False and a.Kod_G IN (select Kod from SprGTovar where Kod_R<>2) В топку. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 15:04 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
хм. А откуда в запросе TOP взялся? Какой сервер? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 15:05 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
Андрей Рябенко1. Таблица "Остатки" - в которой хранятся только остатки на последние числа когда было движение, т.е.когда потребуется собрать оборотку за год и столкнуть ее с предыдущем годом, для каких либо интересов начальства одно остатка будет маловато, рубать ей придется ой как долго. Андрей Рябенко2. Таблица "Обороты" - в которой хранятся обороты по каждому товару, напримерНа кой вообще эта таблица, если все можно взять из таблиц первичных документов? Если в первичке будет в одной таблице товар, дата и контрагент и композитный индекс по этим параметрам то предагрегированная таблица оборотов не нужна. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 15:08 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
Симонов ДенисTOP взялся? Какой сервер?если не файрберд, то с селективными хп ждет облом. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 15:09 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
Андрей РябенкоpoQuery: Error 7200: AQE Error: State = S0000; NativeError = 2166; [iAnywhere Solutions][Advantage SQL Engine]SELECT sub-query returns more than one column. Судя вот по этому Sybase ASE. Так ты не в той ветке спрашиваешь. По оптимизации структуры здешние советы конечно подойдут, а вот про оптимизацию запроса лучше в родной ветке спрашивать. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 15:13 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
Ivan_Pisarevskyбыстрым он может быть только если оборотов по товару не много. Да, с маленьким уточнением: оборотов между базовой датой и требуемой. Поэтому базовую дату надо двигать аккуратно, но регулярно так, чтобы она была в матожидании требуемой даты. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2015, 15:13 |
|
|
start [/forum/topic.php?fid=56&gotonew=1&tid=2015148]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
35ms |
get topic data: |
11ms |
get first new msg: |
7ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
others: | 228ms |
total: | 373ms |
0 / 0 |