Всем добрый день! Есть система учета товаров на складах написанная на

PHP.

Простыми словами, платформа показывает количество остатков товара на разных складах.

На данный момент есть таблица products_availability:
id, product_id, warehouse_id, quantity;

Данная структура показывает текущие остатки товаров, но я не смогу посмотреть, допустим, за вчерашний день.

Какие варианты решения задачи вы видите? Как бы вы это реализовали?

Мне нужно по каждому дню хранить количество остатков.

Неужели нужно клонировать таблицу ежедневно?)

Остатки постоянно в течении дня меняются ведь. Нужна историческая таблица

Да, поэтому в голову пришло под конец дня клонировать таблицу остатков)

Вести лог изменений, на его основе можно восстановить состояние за любую дату.

В 23:59 например))

Как она должна выглядеть?

Да именно так, в конце дня копировать остатки в новую таблицу

Самое простое id, product_id, warehouse_id, change_amount, timestamp. А дальше берете текущее состояние и разматываете на столько дней назад, насколько надо. Это если прямо в лоб решение.

в данном случае нужна таблица где описываются все движения товара, т.е. product_id sklad_id amount created_at т.е. при измении кол-ва на складе, у тебя появлется запись 1 1 -1 текущая дата если произошло перемещение товара на другой склад, то будет 1 1 -1 текущая дата 1 2 +1 текущая дата для большей инфомативности можно доавбить тип (перемещение на другой склад, выдано покупателю, утилизация, поступление)

если совсем упороться можно поставить бд от оракла и там можно цеплять фильтрабельный json с хронологией для каждой колонки но думаю размер обьекта не обрадует сервер при извлечении через пару лет)

ты еще не учел что у него с таким числом товара с каждым днем база пополняется в среднем 20к позиций * 10 складов на 200к записей это очень быстро истощит даже uint64 идентификаторы

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

из того что у него написано, я такаого не заметил, он указал что у него всего 20к SKU по 10 складам, это не очень много

Пиши логику перемещений. Всё равно когда нибудь кладовщик накладные попросит.

Event Suorsing по моему хорошое ришения пожете почитат

что будите делат проста по ивену будете добавля новий запис в таблитсу допустим product_historys

Все это уже имеется. Накладные по перемещениям, продажи, приходы, возвраты, отмены и тд. Но этот подход все равно не дает мне получить количество остатков за определенный день, я могу видеть остатки только на текущий день. Структура такая: product_id, warehouse_id, quantity 1 1 50 1 2 30 1 3 5

Твое предложение у меня называется логом движений товара😁 Но все равно нет возможности вытащить конкретное количество остатка за определенный день.

Это не лог модете не обновлять а только дабавлят, например запис 1 это означает поступил товар и второй запис -1 ушол тавар, при сумировне по дате все должен быть в порядке

Помимо еденицы изменения храни ещё состояние или до или после. Или вообще хранить значение после операции перемещении... Или как предложили выше, вести расчёт на конец дня, недели, месяца, так например делает 1С.

Единственно сразу решить, что нельзя менять транзакции (движения, записи в логи), они как бы идут нарастающим и после вставки не корректируюися. Если нужна коррекция, то проводите обратное действие.

Нет, если хорошенько подумаете, это так не будет работать

Почему

можно пересчитывать всю историю вперед с даты изменения, у него же не строгая отчётность

Можете дапустим по имени event a филтроват

Почему не даёт? Ты же можешь сложить приход и расход до определённой даты, если перемещения все имеются.

Точняк. Просто, мы вначале запуска платформы давали возможность редактирования остатков без актов и накладных, поэтому, редакция не будет учитываться 🥴