|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Есть рабочая таблица с остатками товара, где хранятся остатки на каждый день. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
CAID - ИД объекта (склад, магазин) MODID - ИД товара ADATE - дата обновления остатков MODCNT - количество на остатках Есть процедура, которая дает определенное количество товара на любую дату. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
Есть - которая дает все ненулевые остатки на дату. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
Как эти запросы можно оптимизировать? И как можно получить более оптимально ПОСЛЕДНИЕ остатки( текущие). Код работает 7 лет уже, что еще можно наоптимизировать - ума не приложу. Сейчас таблица остатков имеет 4,5 млн записей и получить текущие остатки на магазине например, занимает неприлично много времени. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 20:33 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
GrigoriyFomin, В GETAMOUNTS4MODID - нужен SELECT FIRST 1 ORDER BY CAID DESC, MODID DESC, ADATE DESC и индекс CREATE DESCENDING INDEX AMOUNTS_DESC ON AMOUNTS (CAID, MODID, MODID); Во 2-й процедуре - нужен SELECT по таблице товаров и JOIN GETAMOUNTS4MODID(...) ON 1=1 ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 20:53 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
GrigoriyFomin, планы и статистика выполнения - где ? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 21:54 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Привет. Сейчас таблица остатков имеет 4,5 млн записей и получить текущие остатки на магазине например, занимает неприлично много времени. Я так понимаю, нарекания вызывает время выполнения процедуры GETAMOUNTS? Идея заключается в том, что бы в цикле определять максимальную дату для каждого товара, а потом по этому товару и максимальной дате извлекать остатки: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28.
Ну, и убывающий индекс по дате будет не лишним ) Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 23:50 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
GrigoriyFomin Как эти запросы можно оптимизировать? И как можно получить более оптимально ПОСЛЕДНИЕ остатки( текущие). Код работает 7 лет уже, что еще можно наоптимизировать - ума не приложу. Сейчас таблица остатков имеет 4,5 млн записей и получить текущие остатки на магазине например, занимает неприлично много времени. На такой структуре уж совсем шустренько текущие остатки никак не получить. У коллеги YuRock там описочка в индексе, имелось в виду, конечно, CREATE DESCENDING INDEX AMOUNTS_DESC ON AMOUNTS (CAID, MODID, ADATE), это даст выигрыш, но незначительный. Эта структура - журнал остатков, скорее, даже не остатков, а операций с остатком после выполнения операции. Она хороша для необходимых , но относительно редких запросов по остаткам на произвольную дату, с которыми можно и потерпеть. А текущие остатки надо хранить в таблице без истории. И можно, если журнал действительно не содержит никаких ссылок-атрибутов насчёт операций, приводящих к изменениям остатков, из приложения вносить изменения только в эту таблицу, а журнал вести на её триггерах. ЗЫ Чота я в последние дни рас... рас... разболтался, короче, надо и честь знать ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 23:57 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Старый плюшевый мишка (CAID, MODID, ADATE) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2021, 00:17 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
GrigoriyFomin, Как вариант - заведите под текущие остатки отдельную табличку. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2021, 05:26 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
История остатков за какой период? Если 7 лет, то зачем? Можно хранить остатки за последний месяц, например. Все старые агрегировать, как начальный остаток. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2021, 07:14 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Старый плюшевый мишка ЗЫ Чота я в последние дни рас... рас... разболтался, короче ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2021, 08:59 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Вариант: хранить только текущие остатки в отдельной таблице. Имея историю операций, можно легко вычислить остаток на любую дату. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2021, 19:11 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Этот вариант во-первых, сделает создаст очередь к записи в таблице, а во-вторых затормозит получение остатков до O(N). Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2021, 19:19 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Exteris История остатков за какой период? Если 7 лет, то зачем? Можно хранить остатки за последний месяц, например. Все старые агрегировать, как начальный остаток. ну не все товары продаются сразу, если товар сезонный, он может по 9 месяцев на складе ждать своего сезона, некоторые позиции годами не продаются. В свое время просто количество товара было пару тысяч и операций - 20тыс., а сейчас со временем все выросло на порядки! Щас сделал таблицу временных остатков, но ее формирование занимает 3-4 минуты на неслабом железе. Когда делалась такая структура хотелось уйти от операции "закрыть день" или "сохранить остатки на конец дня". Так получается рантаймовый сопосб получить остатки на любой день и соотв. выводить товарный отчет за любой период. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2021, 19:55 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Этот вариант во-первых, сделает создаст очередь к записи в таблице, а во-вторых затормозит получение остатков до O(N). Мы так сделали. Работает быстро, если не пытаться получить остаток годичной давности. Обычно нужно знать текущий остаток. Иногда на начало месяца. Конечно зависит от количества транзакций в базе. Очередь транзакций это беда, если больше 4х касс. Для АЗС такого не бывает. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2021, 20:13 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
У меня рассчитанные остатки находятся в одной таблице с движением. Любая операция движения это 2 строки: 1) Откуда, дата, ид товара, -количество, -сумма признак "движение" 2) Куда, дата, ид товара, количество, сумма, признак "движение" Кроме того периодически можно закрывать период. Создается запись Место хранения, дата, ид товара, количество, сумма, признак "остаток" Остаток на любую дату считается как сумма Остаток на "ближайший к требуемой дате" закрытый период + движение за период от даты закрытия до текущей. Подробнее описывал здесь и здесь ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2021, 22:37 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Шавлюк Евгений Любая операция движения это 2 строки: Стрёмная у вас технология - делать проводку двумя разными опосредованно связанными записями. Это всё равно что делать базу данных без внешних ключей. Вполне возможно, что программировать это легче и работает быстрее, но в надежности вашей конструкции я сомневаюсь. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.03.2021, 13:26 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
ggreggoryв надежности вашей конструкции я сомневаюсь. У меня для тебя есть новость: некоторое время назад весьма неглупые люди придумали штуку под названием "транзакция" со свойством атомарности. И, кстати, записей на операцию может быть гораздо больше, чем две. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.03.2021, 13:45 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov И, кстати, записей на операцию может быть гораздо больше, чем две. Да хоть сто, на надежность это не влияет. А у него - сумма в двух экземплярах в базе. Похоже - одна для директора, а другая для своего кармана. Скажите где ваша система работает, я покажу как можно воровать. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.03.2021, 14:25 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
ggreggory Dimitry Sibiryakov И, кстати, записей на операцию может быть гораздо больше, чем две. Да хоть сто, на надежность это не влияет. А у него - сумма в двух экземплярах в базе. Похоже - одна для директора, а другая для своего кармана. Скажите где ваша система работает, я покажу как можно воровать. Точно-точно. Весь этот дурацкий бухучёт построен на принципе двойной записи, который от лукавого. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.03.2021, 14:35 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
ggreggoryА у него - сумма в двух экземплярах в базе. Не в двух. На каждый склад - своя сумма. А складов может быть много. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.03.2021, 14:36 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
GrigoriyFomin, Кстати, безотносительно темы - всё не мог понять что мне вот здесь Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9.
на уровне подсознания режет глаз, и вдруг дошло. Не знаю, может это уже и не актуально, а преданье старины глубокой, но были какие-то глюки с повторным использованием параметра во вложенном селекте. Какие - не помню, лет 15 точно уже на рефлексе пишу только так Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9.
Бережёного бог бережёт. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.03.2021, 14:44 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
ggreggory, Почитайте про принцип двойной записи, это будет вам полезно. Ему всего-то 700 лет. Ну и про транзакции заодно. На каждую операцию, как выше сказали, может быть гораздо больше чем строки, но это принцип. Азы бух.учета. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.03.2021, 22:22 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Есть документ, а есть операции (проводки) по этому документу. Никакого редактирования проводок отдельно от документа не существует. Любая операция это две операции: 1) уходит со "склада А" на "сумму"; 2) приходит на "склад Б" на "сумму"; Все отчеты в такой структуре тривиальные и быстрые. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.03.2021, 22:26 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Шавлюк Евгений Есть документ, а есть операции (проводки) по этому документу. Никакого редактирования проводок отдельно от документа не существует. Любая операция это две операции: 1) уходит со "склада А" на "сумму"; 2) приходит на "склад Б" на "сумму"; Все отчеты в такой структуре тривиальные и быстрые. А "суммы" разные? Если одинаковые, то зачем две операции? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2021, 12:55 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
KreatorXXI А "суммы" разные? Если одинаковые, то зачем две операции? Бывают операции не парные (просто списание и просто приход). (для движений склада, не бухучёта) А ещё, кроме склада и суммы, бывают другие реквизиты записей, и они могут различаться. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2021, 15:23 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
GrigoriyFomin И как можно получить более оптимально ПОСЛЕДНИЕ остатки( текущие). Чтобы удобно получать остатки на дату, нужно создать таблицу хранимых агрегатов (промежуточных итогов), расчёты на начало месяца, к примеру. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2021, 15:43 |
|
|
start [/forum/topic.php?fid=40&fpage=7&tid=1560068]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
162ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
others: | 250ms |
total: | 526ms |
0 / 0 |