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

#mysql #база_данных

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


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



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

Ответы

Ответ 1

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

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


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

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

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

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

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


Ответ 2

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


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


И почитайте учебник русского языка на досуге.