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

254

26 ноября 2016, 20:16

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

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

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

Answer 1

Таблицу операций предлагаю сделать с следующей структурой:

   Операции товаров {
    ID-записи,
    ID-товара,
    ID-операции, если есть справочник типовых операций или ее название и т.п.
    цена операции,
    Дата начала действия,
    Дата окончания действия (01.01.3000 для самых последних операций/расценок)
   }

В таблице заказов или еще где нибудь храните дату изготовления, т.е. дату на которую берется перечень операций/цен. Необходимый набор операций в любых расчетах берется как ДатаИзготовления between ДатаНачала and ДатаОкончания. При изменении расценки на конкретную операцию с 12.01.2016 в старой записи ставится дата окончания 11.01.2016 и добавляется такая же запись с датой начала 12.01 и окончания 01.01.3000. Если операция более не выполняется, то только меняется дата у старой записи.

Таким образом с одной стороны у вас хранится вся история изменения операций/цен и вы можете посчитать что угодно. С другой стороны вам не надо к каждому заказу хранить полный перечень всех выполненных действий.

Если по какой то причине ценообразование более сложное и даты начала действия не достаточно, то можно ввести таблицу "Версии цен", где каждой версии будет назначен ID и под версию храните перечень операций, а в заказе тогда фиксируете, что N экземпляров товара изготовлено по версии цен такой то.

P.S. Еще один плюс такой схемы хранения: вы можете заранее вносить в систему "цены, которые начнут действовать через месяц". Работающим с системой не придется срочно, в авральном режиме вносить цены в последнюю минуту.

Из минусов: логика немного сложнее из за дат. Возможно стоит реализовать триггер или другие методы контроля, которые не позволят поставить дату окончания действия расценки меньшую, чем уже есть в учтенных заказах с данным товаром. Хотя можно ограничится правилом, что дату окончания нельзя поставить меньше текущей.

Answer 2

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