powered by simpleCommunicator - 2.0.50     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / помогите максимально оптимизировать
47 сообщений из 47, показаны все 2 страниц
помогите максимально оптимизировать
    #40057013
GrigoriyFomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Есть рабочая таблица с остатками товара, где хранятся остатки на каждый день.
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
CREATE TABLE AMOUNTS (
    CAID    D_ID NOT NULL /* D_ID = INTEGER */,
    MODID   D_ID NOT NULL /* D_ID = INTEGER */,
    ADATE   D_DATE DEFAULT 'now' NOT NULL /* D_DATE = DATE */,
    MODCNT  D_PRICE /* D_PRICE = NUMERIC(15,2) */
);

ALTER TABLE AMOUNTS ADD CONSTRAINT PK_AMOUNTS PRIMARY KEY (CAID, MODID, ADATE);

CREATE INDEX AMOUNTS_IDX1 ON AMOUNTS (MODID);



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.
create or alter procedure GETAMOUNTS4MODID (
    ACAID_ D_ID,
    MODID_ D_ID,
    ADATE_ D_DBDATE)
returns (
    MODCNT D_PRICE)
as
begin
  select MODCNT
  from AMOUNTS AA
  where (CAID = :ACAID_) and
        (MODID = :MODID_) and
        (ADATE = (select max(ADATE)
                  from AMOUNTS A1
                  where (A1.CAID = :ACAID_) and
                        (A1.MODID = :MODID_) and
                        A1.ADATE <= :ADATE_))
  into :MODCNT;
  suspend;
end


Есть - которая дает все ненулевые остатки на дату.
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
create or alter procedure GETAMOUNTS (
    ADATE D_DATE,
    CAID D_ID)
returns (
    MODID_ D_ID,
    ADATE_ D_DATE,
    MODCNT_ D_PRICE)
as
begin
  for select AA.MODID, AA.ADATE, AA.MODCNT
      from AMOUNTS AA
      where (AA.CAID = :CAID) and
            (AA.ADATE = (select max(ADATE)
                         from AMOUNTS A1
                         where (A1.CAID = :CAID) and
                               (A1.MODID = AA.MODID) and
                               (A1.ADATE <= :ADATE)))
      into :MODID_, :ADATE_, :MODCNT_
  do
    suspend;
end




Как эти запросы можно оптимизировать? И как можно получить более оптимально ПОСЛЕДНИЕ остатки( текущие). Код работает 7 лет уже, что еще можно наоптимизировать - ума не приложу. Сейчас таблица остатков имеет 4,5 млн записей и получить текущие остатки на магазине например, занимает неприлично много времени.
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057015
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057030
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GrigoriyFomin,

планы и статистика выполнения - где ?
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057049
Polesov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Привет.

Сейчас таблица остатков имеет 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.
create or alter procedure GETAMOUNTS (
    ADATE D_DATE,
    CAID D_ID)
returns (
    MODID_  D_ID,
    ADATE_  D_DATE,
    MODCNT_ D_PRICE)
as
begin
  for
    select a.MOID,
           max ( a.ADATE )
      from AMOUNTS a
     where a.CAID  = :CAID
       and a.ADATE <= :ADATE
     group by a.MOID
      into :MODID_,
           :ADATE_
  do
  begin
    MODCNT_ = ( select MODCNT
                  from AMOUNTS
                 where CAID  = :CAID
                   and MODID = :MODID_
                   and ADATE = :ADATE_ );
    suspend;
  end
end



Ну, и убывающий индекс по дате будет не лишним )
Код: sql
1.
create descending index IDX_AMOUNTS_ADATE on AMOUNTS ( ADATE );
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057051
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GrigoriyFomin

Как эти запросы можно оптимизировать? И как можно получить более оптимально ПОСЛЕДНИЕ остатки( текущие). Код работает 7 лет уже, что еще можно наоптимизировать - ума не приложу. Сейчас таблица остатков имеет 4,5 млн записей и получить текущие остатки на магазине например, занимает неприлично много времени.


На такой структуре уж совсем шустренько текущие остатки никак не получить. У коллеги YuRock там описочка в индексе, имелось в виду, конечно, CREATE DESCENDING INDEX AMOUNTS_DESC ON AMOUNTS (CAID, MODID, ADATE), это даст выигрыш, но незначительный. Эта структура - журнал остатков, скорее, даже не остатков, а операций с остатком после выполнения операции. Она хороша для необходимых , но относительно редких запросов по остаткам на произвольную дату, с которыми можно и потерпеть. А текущие остатки надо хранить в таблице без истории. И можно, если журнал действительно не содержит никаких ссылок-атрибутов насчёт операций, приводящих к изменениям остатков, из приложения вносить изменения только в эту таблицу, а журнал вести на её триггерах.

ЗЫ Чота я в последние дни рас... рас... разболтался, короче, надо и честь знать
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057056
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Старый плюшевый мишка
(CAID, MODID, ADATE)
Да, благодарю
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057074
Barkan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GrigoriyFomin,

Как вариант - заведите под текущие остатки отдельную табличку.
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057081
Фотография Exteris
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
История остатков за какой период? Если 7 лет, то зачем? Можно хранить остатки за последний месяц, например. Все старые агрегировать, как начальный остаток.
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057086
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Старый плюшевый мишка
ЗЫ Чота я в последние дни рас... рас... разболтался, короче
Для чего же ещё нужон форум?!
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057253
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вариант: хранить только текущие остатки в отдельной таблице. Имея историю операций, можно легко вычислить остаток на любую дату.
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057255
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Этот вариант во-первых, сделает создаст очередь к записи в таблице, а во-вторых затормозит
получение остатков до O(N).
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057266
GrigoriyFomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Exteris
История остатков за какой период? Если 7 лет, то зачем? Можно хранить остатки за последний месяц, например. Все старые агрегировать, как начальный остаток.

ну не все товары продаются сразу, если товар сезонный, он может по 9 месяцев на складе ждать своего сезона, некоторые позиции годами не продаются. В свое время просто количество товара было пару тысяч и операций - 20тыс., а сейчас со временем все выросло на порядки! Щас сделал таблицу временных остатков, но ее формирование занимает 3-4 минуты на неслабом железе. Когда делалась такая структура хотелось уйти от операции "закрыть день" или "сохранить остатки на конец дня". Так получается рантаймовый сопосб получить остатки на любой день и соотв. выводить товарный отчет за любой период.
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057269
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov

Этот вариант во-первых, сделает создаст очередь к записи в таблице, а во-вторых затормозит
получение остатков до O(N).


Мы так сделали. Работает быстро, если не пытаться получить остаток годичной давности. Обычно нужно знать текущий остаток. Иногда на начало месяца. Конечно зависит от количества транзакций в базе.

Очередь транзакций это беда, если больше 4х касс. Для АЗС такого не бывает.
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057299
Шавлюк Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня рассчитанные остатки находятся в одной таблице с движением.
Любая операция движения это 2 строки:
1) Откуда, дата, ид товара, -количество, -сумма признак "движение"
2) Куда, дата, ид товара, количество, сумма, признак "движение"

Кроме того периодически можно закрывать период. Создается запись
Место хранения, дата, ид товара, количество, сумма, признак "остаток"

Остаток на любую дату считается как сумма
Остаток на "ближайший к требуемой дате" закрытый период + движение за период от даты закрытия до текущей.
Подробнее описывал здесь и здесь
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057369
ggreggory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Шавлюк Евгений

Любая операция движения это 2 строки:


Стрёмная у вас технология - делать проводку двумя разными опосредованно связанными записями. Это всё равно что делать базу данных без внешних ключей. Вполне возможно, что программировать это легче и работает быстрее, но в надежности вашей конструкции я сомневаюсь.
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057374
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ggreggoryв надежности вашей конструкции я сомневаюсь.

У меня для тебя есть новость: некоторое время назад весьма неглупые люди придумали штуку
под названием "транзакция" со свойством атомарности. И, кстати, записей на операцию может
быть гораздо больше, чем две.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057377
ggreggory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov

И, кстати, записей на операцию может
быть гораздо больше, чем две.


Да хоть сто, на надежность это не влияет. А у него - сумма в двух экземплярах в базе. Похоже - одна для директора, а другая для своего кармана. Скажите где ваша система работает, я покажу как можно воровать.
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057380
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ggreggory
Dimitry Sibiryakov

И, кстати, записей на операцию может
быть гораздо больше, чем две.


Да хоть сто, на надежность это не влияет. А у него - сумма в двух экземплярах в базе. Похоже - одна для директора, а другая для своего кармана. Скажите где ваша система работает, я покажу как можно воровать.


Точно-точно. Весь этот дурацкий бухучёт построен на принципе двойной записи, который от лукавого.
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057382
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ggreggoryА у него - сумма в двух экземплярах в базе.

Не в двух. На каждый склад - своя сумма. А складов может быть много.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057385
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GrigoriyFomin,

Кстати, безотносительно темы - всё не мог понять что мне вот здесь
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
  select MODCNT
  from AMOUNTS AA
  where (CAID = :ACAID_) and
        (MODID = :MODID_) and
        (ADATE = (select max(ADATE)
                  from AMOUNTS A1
                  where (A1.CAID = :ACAID_) and
                        (A1.MODID = :MODID_) and
                        A1.ADATE <= :ADATE_))



на уровне подсознания режет глаз, и вдруг дошло. Не знаю, может это уже и не актуально, а преданье старины глубокой, но были какие-то глюки с повторным использованием параметра во вложенном селекте. Какие - не помню, лет 15 точно уже на рефлексе пишу только так

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
  select MODCNT
  from AMOUNTS AA
  where (CAID = :ACAID_) and
        (MODID = :MODID_) and
        (ADATE = (select max(ADATE)
                  from AMOUNTS A1
                  where (A1.CAID = AA.ACAID_) and
                        (A1.MODID = AA.MODID_) and
                        A1.ADATE <= :ADATE_))



Бережёного бог бережёт.
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057462
Шавлюк Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ggreggory,

Почитайте про принцип двойной записи, это будет вам полезно. Ему всего-то 700 лет.
Ну и про транзакции заодно.
На каждую операцию, как выше сказали, может быть гораздо больше чем строки, но это принцип. Азы бух.учета.
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40057464
Шавлюк Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть документ, а есть операции (проводки) по этому документу.
Никакого редактирования проводок отдельно от документа не существует.

Любая операция это две операции:
1) уходит со "склада А" на "сумму";
2) приходит на "склад Б" на "сумму";

Все отчеты в такой структуре тривиальные и быстрые.
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059081
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Шавлюк Евгений
Есть документ, а есть операции (проводки) по этому документу.
Никакого редактирования проводок отдельно от документа не существует.

Любая операция это две операции:
1) уходит со "склада А" на "сумму";
2) приходит на "склад Б" на "сумму";

Все отчеты в такой структуре тривиальные и быстрые.

А "суммы" разные? Если одинаковые, то зачем две операции?
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059135
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
KreatorXXI
А "суммы" разные? Если одинаковые, то зачем две операции?
Может, лучше вообще ничего не писать, а просто таблички на складах перевесить?
Бывают операции не парные (просто списание и просто приход). (для движений склада, не бухучёта)
А ещё, кроме склада и суммы, бывают другие реквизиты записей, и они могут различаться.
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059139
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GrigoriyFomin
И как можно получить более оптимально ПОСЛЕДНИЕ остатки( текущие).
Чтобы их получить, их необходимо хранить. В таблице остатков.

Чтобы удобно получать остатки на дату, нужно создать таблицу хранимых агрегатов (промежуточных итогов), расчёты на начало месяца, к примеру.
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059219
GrigoriyFomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
WildSery,

что хранить остатки за день - надо, чтоб кто-то делал закрытие дня или делать это автоматом (FB триггеров по времени вроде не умеет), то есть это должен делать человек, а товар может приходить и оприходываться ночью
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059220
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GrigoriyFomin
(FB триггеров по времени вроде не умеет), то есть это должен делать человек
man crontab
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059232
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GrigoriyFominа товар может приходить и оприходываться ночью

Совершенно всё равно. Никто ведь не заставляет тебя закрывать сегодняшний день. День
недельной давности закрывается даже проще.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059241
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GrigoriyFomin
WildSery,

что хранить остатки за день - надо, чтоб кто-то делал закрытие дня или делать это автоматом (FB триггеров по времени вроде не умеет), то есть это должен делать человек, а товар может приходить и оприходываться ночью


Да не на день, а на текущую, грубо говоря, секунду. В оперативной работе, на которую приходится деятельность 80% сотрудников, нужны именно они. А бухгалтеры и аналитики пусть работают себе с журналом. Решение от Евгения Шавлюка для этого оптимальное, удачное применение бухгалтерского приёма в оперативном учёте. У бухгалтеров своя свадьба и у них всё должно быть по своему, вплоть до вообще своей отдельной базы во избежание лишних вопросов из внешнего мира, у аналитиков своя. Я вот делал для них не двойную запись, а приходы и расходы со знаком в тех же целях - получать результат через SUM. У него, пожалуй, проще, за счёт увеличения объёма данных. Я-то это проектировал когда прогрессивный корпоративный сервер был на двухголовом Р90 с рейдом аж на четырёх дисках по 1Гб, об объёмах приходилось думать очень внимательно. Так пережиток и живёт поныне. А насчёт вложенных селектов в запросах к действительно большим объёмам данных - когда я их вижу, указательный пальчик правой руки тянется к спусковому крючку пистолета :))
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059295
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Старый плюшевый мишкаЯ вот делал для них не двойную запись, а приходы и расходы со знаком в тех же целях

Дед, ты не поверишь, но это и есть двойная запись: когда одно движение денег записывается
дважды, в одно место с плюсом, а в другое - с минусом.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059309
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov

Старый плюшевый мишкаЯ вот делал для них не двойную запись, а приходы и расходы со знаком в тех же целях

Дед, ты не поверишь, но это и есть двойная запись: когда одно движение денег записывается
дважды, в одно место с плюсом, а в другое - с минусом.


Не, ты не понял. Или не совсем понял. Или я неправильно выразился. Или не совсем правильно. Или не полно. Или...
Короче, примерно так у меня выглядит складская карточка в оперативном, не бух, учёте, тот самый журнал итогов складских операций

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
SHOW TABLE sklchart
KODTOV                          INTEGER Not Null 
STORE                           INTEGER Not Null /*ID склада*/
TIPZAP                          INTEGER Not Null 
DZCODE                          INTEGER Not Null /*ID операции, в том числе инвентаризаций*/
KOLINT                          INTEGER Not Null 
DATEZAV                         DATE Nullable Default "NOW"
/*не относящиеся к вопросу атрибуты*/
RZKOLINT                        INTEGER Nullable default 0

CONSTRAINT SKCR_PK:
  Primary key (KODTOV, STORE, TIPZAP, DZCODE)
CONSTRAINT SKCR_FKNOM:
  Foreign key (KODTOV)    References NOMENKL (CODE)
CONSTRAINT SKCR_FKDZ:
  Foreign key (STORE, DZCODE)    References DVIG_ZAP (STORE, CODE)



Уж прости что не из Эксперта, WISQL запускается быстрее и вообще всё в одном окошке видно ;) Остаток - RZKOLINT, изменение - KOLINT, и вот оно при приходе положительное, при расходе отрицательное. При перемещении запасов между складами фирмы будет, разумеется, и вторая запись, после регистрации прихода на другом складе. И не факт, что того же товара и такое же количество, грузчики всё-таки люди, а людЯм, как известно, свойственно ошибаться и иногда совать не то, не туда и не столько. А при поступлении из внешнего мира и при уходе в оный второй записи не будет. Так что двойная запись тут такая... сусликоподобная, вроде и есть, а вроде и нету :)
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059321
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Старый плюшевый мишкаНе, ты не понял. Или не совсем понял. Или я неправильно выразился. Или не совсем
правильно. Или не полно. Или...

Да всё я понял. Просто тут надо иметь немного опыта ведения бухгалтерии на бумаге.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059564
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WildSery
KreatorXXI
А "суммы" разные? Если одинаковые, то зачем две операции?
Может, лучше вообще ничего не писать, а просто таблички на складах перевесить?
Бывают операции не парные (просто списание и просто приход). (для движений склада, не бухучёта)
А ещё, кроме склада и суммы, бывают другие реквизиты записей, и они могут различаться.

Есть о чём спорить. Вот я в своё время подсмотрел у грандов технику и так делаю. Есть получатель, есть отправитель, есть сумма. Есть ещё тип операции. Одна запись. Бухгалтерия в принципе также устроена. Дебет, кредит, сумма.
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059594
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
KreatorXXI

Есть о чём спорить. Вот я в своё время подсмотрел у грандов технику и так делаю. Есть получатель, есть отправитель, есть сумма. Есть ещё тип операции. Одна запись. Бухгалтерия в принципе также устроена. Дебет, кредит, сумма.


Вообще-то получатель и отправитель - это атрибуты-ключи транспортной партии, а не складской операции. И их в этой ТП может быть не по одному. СО с ТП связана, через соответствующие таблички, разумеется, но не всегда. А СО, связанная с движением запасов, - это обычно не выдача студенту буханки хлеба, а приёмка-отгрузка вагончика тонн на 60 со всякой тварью по паре внутре. И у этой СО тоже есть состав. А вот бухгалтерию эти нюансы редко интересуют, хотя случается. На грандство не претендую, если чо :)
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059598
Шавлюк Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
KreatorXXI,

Суммы всегда одинаковые. Разные "склады" и "знак"
Минус со "склада А" плюс на "склад Б".
Для получения остатков на текущий момент суммируются значения по нужному складу
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059675
a7exander
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Насчет получения остатков с одной таблицей хотел бы дополнить своим способом которым пользуюсь много лет:

остатки хранятся в таблице движения датой "01.01.2100" со знаком минус
соответственно остаток на любой момент выбирается SUM по датам > даты нужного момента.

корректность остатков легко проверяется общим суммированием - сумма должна быть всегда 0

один из больших плюсов - остатки на самые используемые периоды получаются быстрее всего, кроме того старые даты легко отрезать в случае складирования в архив
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059716
Шавлюк Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
a7exander,

А когда пересчитывается '01.01.2100'?
Или каждое движение добавляет и в эту дату?
Остатки на эту дату изменяются обновлением вставкой или обновлением строки (тут возможны конфликты)?

Обрезка данных и в моей модели не сложно. Т.к. остатки всегда считаются начиная от какой-то даты, то все что раньше можно без проблем обрезать
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059724
a7exander
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Шавлюк Евгений,

строка на 01.01.2100 обновляется триггером при добавлении/удалении/изменении любой другой строки кроме этой даты.

За много лет эта схема сбоев не давала в продакшене, правда нагрузки небольшие, до 40 пользователей работают
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059726
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
05.04.2021 12:23, a7exander пишет:
> строка на 01.01.2100 обновляется триггером при добавлении/удалении/изменении любой другой строки кроме этой даты.
> За много лет эта схема сбоев не давала в продакшене, правда нагрузки небольшие, до 40 пользователей работают

с каким уровнем изоляции?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059731
a7exander
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мимопроходящий,

Везде read_committed

в процедуре проводки после вставки еще контроль делается - SUM чтобы было 0, а если не то эксепшн

думал если будут проблемы то вместо одной строки с ее апдейтами буду делать отдельную для каждой операции и потом ночью их в одну сжимать. Но работа устраивает, так что оставил так.
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059734
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
05.04.2021 12:38, a7exander пишет:
>
> Везде read_committed

дальше обсуждать нет смысла.
удачи в ловле покемонов.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059735
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
a7exander
Шавлюк Евгений,

строка на 01.01.2100 обновляется триггером при добавлении/удалении/изменении любой другой строки кроме этой даты.

За много лет эта схема сбоев не давала в продакшене, правда нагрузки небольшие, до 40 пользователей работают
Не очень понятно, как update в триггере мог за "много лет" не привести к конфликтам при работе 40 пользователей.
Можно, конечно, предположить, что они "Повтор" нажимают, пока не нажмется.
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059741
a7exander
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRock, Мимопроходящий

Ну так это в любой схеме возможно, и с отдельной таблицей для остатков и с остатками помесячно, без разницы.
Я лишь подсказал идею, которой пользуюсь сам - минимум дополнительный строк, очень простые SQL для получения остатков, максимальная скорость получения на последнюю дату, быстрый и простой метод верификации, минимум логики обвязки для работы

далее кому какие шашечки - реализовываем по вкусу
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059742
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockНе очень понятно, как update в триггере мог за "много лет" не привести к конфликтам при
работе 40 пользователей.

Они продают разные товары. Поэтому каждый остаток изменяется максимум одним пользователем.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059745
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
05.04.2021 12:50, Dimitry Sibiryakov пишет:
> Они продают разные товары.


Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40059774
ggreggory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Мимопроходящий

05.04.2021 12:38, a7exander пишет:
>
> Везде read_committed

дальше обсуждать нет смысла.
удачи в ловле покемонов.


Использование for update with lock при доступе к агрегатам обеспечит корректную работу для read_committed. Разве нет?
...
Рейтинг: 0 / 0
помогите максимально оптимизировать
    #40060021
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRock

Не очень понятно, как update в триггере мог за "много лет" не привести к конфликтам при работе 40 пользователей.
Можно, конечно, предположить, что они "Повтор" нажимают, пока не нажмется.

Именно так. Безотносительно триггера - у меня завершение складской операции может продолжаться минут 10. Это, разумеется, крайний случай, когда в вагоне о 60 тоннах сотня наименований. Которые отстреливают в текущее состояние запасов и в ценовые группы, не говоря уж о резервах филиалов на товары. Короче, 17 страниц тексту ХП. Правда, там concurrency, работа в приращениях, а не присваиваниях, и 6 раз "повтор" нажимает application server, но за 20 с лихуем лет сообщение - попробуйте повторить позже - вылезало 4 раза. Это как раз случаи по 10 минут. В общем, каждая ложка хороша к своему обеду. Возможностей море, выбрать под свою ситуацию есть из чего, а панацеи нетути.
...
Рейтинг: 0 / 0
47 сообщений из 47, показаны все 2 страниц
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / помогите максимально оптимизировать
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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