Comments 4
Логично, что вам непонятно. Вы используете совершенно иную терминологию, плюс решали разные задачи…
Из прочитанного я вообще не понял какое отношение всё что вы сделали имеет к собственно себестоимости.
Из прочитанного я вообще не понял какое отношение всё что вы сделали имеет к собственно себестоимости.
В задаче Fifo/Lifo главной проблемой в оперативном списании, наверное можно назвать связывание расхода с приходом один ко многим. Основные подходы в решении: создание промежуточных итогов, хранение связей расхода и приходов.
Такой подход позволяет быстро посчитать себестоимость расхода следующей транзакции, но значительно усложняет работу в случае, если вносятся правки задним числом, или транзакции приходят не по порядку в течении дня и нужно также инициировать пересчет уже совершенных сделок. Также повышает денормализацию и связанность данных в БД, что приводит к эскалации блокировок при реальных нагрузках.
Считаю, что сейчас эту проблему нужно решать не так, как 10 лет назад. А именно, вместо того, чтобы мыслить на уровне реляционной БД с хранением связей и остатков, можно поддерживать списки транзакций актуального периода в оперативной памяти. Например, при нагрузке 1 млн транзакций в час, и предположению, что активный период изменений может составить календарный месяц, ну и пускай 60 байт на запись транзакции, то получается менее 16Gb памяти в потокобезопасной структуре.
При этом в памяти можно делать дорогие операции просмотра всех транзакций 1 клиента по 1 товару от начала периода, в хранилище же помещать только факт совершения транзакции.
Такой подход позволяет быстро посчитать себестоимость расхода следующей транзакции, но значительно усложняет работу в случае, если вносятся правки задним числом, или транзакции приходят не по порядку в течении дня и нужно также инициировать пересчет уже совершенных сделок. Также повышает денормализацию и связанность данных в БД, что приводит к эскалации блокировок при реальных нагрузках.
Считаю, что сейчас эту проблему нужно решать не так, как 10 лет назад. А именно, вместо того, чтобы мыслить на уровне реляционной БД с хранением связей и остатков, можно поддерживать списки транзакций актуального периода в оперативной памяти. Например, при нагрузке 1 млн транзакций в час, и предположению, что активный период изменений может составить календарный месяц, ну и пускай 60 байт на запись транзакции, то получается менее 16Gb памяти в потокобезопасной структуре.
При этом в памяти можно делать дорогие операции просмотра всех транзакций 1 клиента по 1 товару от начала периода, в хранилище же помещать только факт совершения транзакции.
Sign up to leave a comment.
К вопросу расчета себестоимости