|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#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 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
WildSery, что хранить остатки за день - надо, чтоб кто-то делал закрытие дня или делать это автоматом (FB триггеров по времени вроде не умеет), то есть это должен делать человек, а товар может приходить и оприходываться ночью ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2021, 22:42 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
GrigoriyFomin (FB триггеров по времени вроде не умеет), то есть это должен делать человек ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2021, 22:54 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
GrigoriyFominа товар может приходить и оприходываться ночью Совершенно всё равно. Никто ведь не заставляет тебя закрывать сегодняшний день. День недельной давности закрывается даже проще. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2021, 00:23 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
GrigoriyFomin WildSery, что хранить остатки за день - надо, чтоб кто-то делал закрытие дня или делать это автоматом (FB триггеров по времени вроде не умеет), то есть это должен делать человек, а товар может приходить и оприходываться ночью Да не на день, а на текущую, грубо говоря, секунду. В оперативной работе, на которую приходится деятельность 80% сотрудников, нужны именно они. А бухгалтеры и аналитики пусть работают себе с журналом. Решение от Евгения Шавлюка для этого оптимальное, удачное применение бухгалтерского приёма в оперативном учёте. У бухгалтеров своя свадьба и у них всё должно быть по своему, вплоть до вообще своей отдельной базы во избежание лишних вопросов из внешнего мира, у аналитиков своя. Я вот делал для них не двойную запись, а приходы и расходы со знаком в тех же целях - получать результат через SUM. У него, пожалуй, проще, за счёт увеличения объёма данных. Я-то это проектировал когда прогрессивный корпоративный сервер был на двухголовом Р90 с рейдом аж на четырёх дисках по 1Гб, об объёмах приходилось думать очень внимательно. Так пережиток и живёт поныне. А насчёт вложенных селектов в запросах к действительно большим объёмам данных - когда я их вижу, указательный пальчик правой руки тянется к спусковому крючку пистолета :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2021, 03:23 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаЯ вот делал для них не двойную запись, а приходы и расходы со знаком в тех же целях Дед, ты не поверишь, но это и есть двойная запись: когда одно движение денег записывается дважды, в одно место с плюсом, а в другое - с минусом. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2021, 12:58 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Старый плюшевый мишкаЯ вот делал для них не двойную запись, а приходы и расходы со знаком в тех же целях Дед, ты не поверишь, но это и есть двойная запись: когда одно движение денег записывается дважды, в одно место с плюсом, а в другое - с минусом. Не, ты не понял. Или не совсем понял. Или я неправильно выразился. Или не совсем правильно. Или не полно. Или... Короче, примерно так у меня выглядит складская карточка в оперативном, не бух, учёте, тот самый журнал итогов складских операций Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Уж прости что не из Эксперта, WISQL запускается быстрее и вообще всё в одном окошке видно ;) Остаток - RZKOLINT, изменение - KOLINT, и вот оно при приходе положительное, при расходе отрицательное. При перемещении запасов между складами фирмы будет, разумеется, и вторая запись, после регистрации прихода на другом складе. И не факт, что того же товара и такое же количество, грузчики всё-таки люди, а людЯм, как известно, свойственно ошибаться и иногда совать не то, не туда и не столько. А при поступлении из внешнего мира и при уходе в оный второй записи не будет. Так что двойная запись тут такая... сусликоподобная, вроде и есть, а вроде и нету :) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2021, 14:01 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаНе, ты не понял. Или не совсем понял. Или я неправильно выразился. Или не совсем правильно. Или не полно. Или... Да всё я понял. Просто тут надо иметь немного опыта ведения бухгалтерии на бумаге. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2021, 14:24 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
WildSery KreatorXXI А "суммы" разные? Если одинаковые, то зачем две операции? Бывают операции не парные (просто списание и просто приход). (для движений склада, не бухучёта) А ещё, кроме склада и суммы, бывают другие реквизиты записей, и они могут различаться. Есть о чём спорить. Вот я в своё время подсмотрел у грандов технику и так делаю. Есть получатель, есть отправитель, есть сумма. Есть ещё тип операции. Одна запись. Бухгалтерия в принципе также устроена. Дебет, кредит, сумма. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2021, 15:20 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
KreatorXXI Есть о чём спорить. Вот я в своё время подсмотрел у грандов технику и так делаю. Есть получатель, есть отправитель, есть сумма. Есть ещё тип операции. Одна запись. Бухгалтерия в принципе также устроена. Дебет, кредит, сумма. Вообще-то получатель и отправитель - это атрибуты-ключи транспортной партии, а не складской операции. И их в этой ТП может быть не по одному. СО с ТП связана, через соответствующие таблички, разумеется, но не всегда. А СО, связанная с движением запасов, - это обычно не выдача студенту буханки хлеба, а приёмка-отгрузка вагончика тонн на 60 со всякой тварью по паре внутре. И у этой СО тоже есть состав. А вот бухгалтерию эти нюансы редко интересуют, хотя случается. На грандство не претендую, если чо :) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2021, 20:45 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
KreatorXXI, Суммы всегда одинаковые. Разные "склады" и "знак" Минус со "склада А" плюс на "склад Б". Для получения остатков на текущий момент суммируются значения по нужному складу ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2021, 23:14 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Насчет получения остатков с одной таблицей хотел бы дополнить своим способом которым пользуюсь много лет: остатки хранятся в таблице движения датой "01.01.2100" со знаком минус соответственно остаток на любой момент выбирается SUM по датам > даты нужного момента. корректность остатков легко проверяется общим суммированием - сумма должна быть всегда 0 один из больших плюсов - остатки на самые используемые периоды получаются быстрее всего, кроме того старые даты легко отрезать в случае складирования в архив ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2021, 11:11 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
a7exander, А когда пересчитывается '01.01.2100'? Или каждое движение добавляет и в эту дату? Остатки на эту дату изменяются обновлением вставкой или обновлением строки (тут возможны конфликты)? Обрезка данных и в моей модели не сложно. Т.к. остатки всегда считаются начиная от какой-то даты, то все что раньше можно без проблем обрезать ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2021, 12:03 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Шавлюк Евгений, строка на 01.01.2100 обновляется триггером при добавлении/удалении/изменении любой другой строки кроме этой даты. За много лет эта схема сбоев не давала в продакшене, правда нагрузки небольшие, до 40 пользователей работают ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2021, 12:23 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
05.04.2021 12:23, a7exander пишет: > строка на 01.01.2100 обновляется триггером при добавлении/удалении/изменении любой другой строки кроме этой даты. > За много лет эта схема сбоев не давала в продакшене, правда нагрузки небольшие, до 40 пользователей работают с каким уровнем изоляции? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2021, 12:25 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Мимопроходящий, Везде read_committed в процедуре проводки после вставки еще контроль делается - SUM чтобы было 0, а если не то эксепшн думал если будут проблемы то вместо одной строки с ее апдейтами буду делать отдельную для каждой операции и потом ночью их в одну сжимать. Но работа устраивает, так что оставил так. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2021, 12:38 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
05.04.2021 12:38, a7exander пишет: > > Везде read_committed дальше обсуждать нет смысла. удачи в ловле покемонов. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2021, 12:40 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
a7exander Шавлюк Евгений, строка на 01.01.2100 обновляется триггером при добавлении/удалении/изменении любой другой строки кроме этой даты. За много лет эта схема сбоев не давала в продакшене, правда нагрузки небольшие, до 40 пользователей работают Можно, конечно, предположить, что они "Повтор" нажимают, пока не нажмется. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2021, 12:41 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
YuRock, Мимопроходящий Ну так это в любой схеме возможно, и с отдельной таблицей для остатков и с остатками помесячно, без разницы. Я лишь подсказал идею, которой пользуюсь сам - минимум дополнительный строк, очень простые SQL для получения остатков, максимальная скорость получения на последнюю дату, быстрый и простой метод верификации, минимум логики обвязки для работы далее кому какие шашечки - реализовываем по вкусу ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2021, 12:49 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
YuRockНе очень понятно, как update в триггере мог за "много лет" не привести к конфликтам при работе 40 пользователей. Они продают разные товары. Поэтому каждый остаток изменяется максимум одним пользователем. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2021, 12:50 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
05.04.2021 12:50, Dimitry Sibiryakov пишет: > Они продают разные товары. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2021, 12:54 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
Мимопроходящий 05.04.2021 12:38, a7exander пишет: > > Везде read_committed дальше обсуждать нет смысла. удачи в ловле покемонов. Использование for update with lock при доступе к агрегатам обеспечит корректную работу для read_committed. Разве нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2021, 13:46 |
|
помогите максимально оптимизировать
|
|||
---|---|---|---|
#18+
YuRock Не очень понятно, как update в триггере мог за "много лет" не привести к конфликтам при работе 40 пользователей. Можно, конечно, предположить, что они "Повтор" нажимают, пока не нажмется. Именно так. Безотносительно триггера - у меня завершение складской операции может продолжаться минут 10. Это, разумеется, крайний случай, когда в вагоне о 60 тоннах сотня наименований. Которые отстреливают в текущее состояние запасов и в ценовые группы, не говоря уж о резервах филиалов на товары. Короче, 17 страниц тексту ХП. Правда, там concurrency, работа в приращениях, а не присваиваниях, и 6 раз "повтор" нажимает application server, но за 20 с лихуем лет сообщение - попробуйте повторить позже - вылезало 4 раза. Это как раз случаи по 10 минут. В общем, каждая ложка хороша к своему обеду. Возможностей море, выбрать под свою ситуацию есть из чего, а панацеи нетути. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2021, 22:56 |
|
|
start [/forum/moderation_log.php?user_name=%D0%92%D0%BE%D0%B2%D0%BA%D0%B0]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
179ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
80ms |
get tp. blocked users: |
2ms |
others: | 693ms |
total: | 1023ms |
0 / 0 |