без посторонних рассуждений/взглядов не обойтись?
а что, такой простой вариант БД может быть настолько неоднозначно интерпретирован относительно нормализации данных
Я попытался сделать combined_zones, это объединение двух массивов, однако это не дало ожидаемого результата. Может кто может помочь, чтобы код работал при нескольких людях
вряд ли получится подать от одной банки
подтолкните ТС в эту сторону ))
Смотрите в чем вопрос.
Если по конкретному складу и по конкретному товару вы храните не одну запись остатка, а всю цепочку, то это называется "журнал", "история" и т.д. В этом случае нужен обычно ещё один идентификатор. Как у вас в схеме.
Такая структура данных позволяет в любой момент рассмотреть динамику расхода товара, отобразить запасы а графике по времени, и т.д. Минусы в описанной схеме есть. Основной - это скорость доступа к снапшоту текущего состояния. Для быстрого доступа к снапшоту текущего состояния нужно добавлять ещё флаг финального состояния и делать с ним индекс. Это компромиссный вариант, поскольку при изменении запаса на складе вам не достаточно добавить одну запись, вам нужно ещё и обновить предыдущий хвостовой элемент, а при этом дважды изменятся индексы.
Правильнее поступать по-другому. Хранить журналы в отдельной таблице, а снапшот в отдельной. Это уже не будет соответствовать формальным требованиям нормализации, НО, зато это будет хорошо и быстро работать на практике.
В реальности мы всегда выбираем компромиссы между избыточностью и скоростью, между сложностью и надёжностью, между реплицируемостью и доступностью... Прочитайте про CAP-теорему.
Во многих случаях прибегают к сознательной денормализации данных в БД, чтобы ускорить некоторые запросы в тысячи раз, на порядки.