Как изменять нужные данные в базе данных?

Всем привет! Прошу прощения за глупую формулировку вопроса! Не придумал лучше. Тяжело описать вопрос поэтому я его нарисовал) Надеюсь поймете! Коротко: Что бы сделать товар нужно выполнить определенное количество операций по определенной цене. Операции могут меняться и цены на них тоже! И поэтому надо как то запоминать для каждого заказного товара эту информацию, что бы можно было посчитать зарплату себестоимость и та далее.
Я пока что вижу только одно решение хранить для каждого товара в каждом заказе операции. Как бы проблем нет, но за какое то время количество строк будет просто огромным!

Надеюсь вы меня поняли! Что вы посоветуете?

Ответ

Таблицу операций предлагаю сделать с следующей структурой:
Операции товаров { ID-записи, ID-товара, ID-операции, если есть справочник типовых операций или ее название и т.п. цена операции, Дата начала действия, Дата окончания действия (01.01.3000 для самых последних операций/расценок) }
В таблице заказов или еще где нибудь храните дату изготовления, т.е. дату на которую берется перечень операций/цен. Необходимый набор операций в любых расчетах берется как ДатаИзготовления between ДатаНачала and ДатаОкончания. При изменении расценки на конкретную операцию с 12.01.2016 в старой записи ставится дата окончания 11.01.2016 и добавляется такая же запись с датой начала 12.01 и окончания 01.01.3000. Если операция более не выполняется, то только меняется дата у старой записи.
Таким образом с одной стороны у вас хранится вся история изменения операций/цен и вы можете посчитать что угодно. С другой стороны вам не надо к каждому заказу хранить полный перечень всех выполненных действий.
Если по какой то причине ценообразование более сложное и даты начала действия не достаточно, то можно ввести таблицу "Версии цен", где каждой версии будет назначен ID и под версию храните перечень операций, а в заказе тогда фиксируете, что N экземпляров товара изготовлено по версии цен такой то.
P.S. Еще один плюс такой схемы хранения: вы можете заранее вносить в систему "цены, которые начнут действовать через месяц". Работающим с системой не придется срочно, в авральном режиме вносить цены в последнюю минуту.
Из минусов: логика немного сложнее из за дат. Возможно стоит реализовать триггер или другие методы контроля, которые не позволят поставить дату окончания действия расценки меньшую, чем уже есть в учтенных заказах с данным товаром. Хотя можно ограничится правилом, что дату окончания нельзя поставить меньше текущей.