Maker
как вариант завести в поле заказа % или величину скидки от основного тарифа - и проблема решена! :). Просто хранить одни и те же данные в таблице ИМХО избыточность большая.

Скидки бывают не только в процентах, но и абсолютных цифрах. Типа, владелец говорит:
- мы Вам тысченку скинем.

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

Я делал так. Есть действующая на текщий момент цена. Оператор получает ее по умолчанию. Далее он вводит или не вводит скидку. В заказе хранится фиксированая для данной позиции и данноного потребителя цена.

Maker
хороший подход, но а если скидок нет и быть не может (утверждённые тарифы)?
всё таки пока думаю привязка по дате - самое то...
И такое тоже делал. Оплата электроэнегрии населением. С кучей льгот, которые действуют от даты до даты, с изменением условий расчета всего, что только можно изменить задним числом. Выяснялось, что этот, оказывается. имеет льготы с такого-то числа, а тот, на самом деле льгот не имеет. Этот, оказывается, должен иметь такой тариф, а тот другой.
Кошмарная база получилась.
В ней мне действительно пришлось применять привязку к датам, вернее к диапазоном действия тарифов, льгот, социальных норм и прочих изврашенных придумок наших законодателей.

А еще надо и нечто сводное выдавать. Типа, как в деревне ДДД обстоят дела с задолженностями, сколько они должны заплатить и сколько заплатили.
Впрочем, любой, кто сталкивался с комунальными платежами или другими биллинговыми системами таких страшилок тысячу расскажет. И покажет жуткие запросы или целые хранимые процедуры жутких запросов.
============
После некоторого размышления я пошел на денормализацию. Создал таблицу, где хранятся конкретные взаиморасчеты, с уже расчитанными тарифами, льготами, социальными нормами и прочей лабудой. Сводная отчетность резко упростилась и стала выдаваться за приемлемое время.

Но это, на мой взгляд, предельный случай. Когда правила игры меняются походу, когда по решению суда нужно изменить данные за последние 10 лет.

В большинстве случаев достаточно хранить только текущие отпускные цены.