if say the particular business has prices which are fixed each calendar year, but differ from year to year,
Call me jaded but when a client tells me something like that, my spidey senses crackle. This kind of statement belongs in the "there will never be more then 3 status dates" category. As soon as I commit to this kind of design, the client decides that inflation is high this year and he wants to increase the price in six months for new orders.
I practice defensive programming. When you have been developing applications as varied as I have and for as many years, you get a good sense for what business rules are actually cast in concrete and which are more flexible. I never build something inflexible like you are suggesting unless I get the client to sign a contract that he isn't going to change his mind - ever
.
The method I suggested might be more flexible than is needed today but it doesn't prevent certain "rules" from changing later. And it doesn't violate any normal forms.
In your example where your pricing table comprises a series of prices with the start/end date range of applicability, the price of an order now or any time in the future can be found by searching for the order date that falls during the effectiveness range.
That is true. However, how do you handle returns (negative values)? How do you handle non-standard pricing (something they type in instead of the book price)? How do you handle replacements (zero cost items)? All of those are handled by simply saving the sale price at the time of this particular sale. Your assumption is absolutely inviolate pricing - no flexibility at all.
You can provide the flexibility to do any of the things I suggested by following my design pattern. You don't need to actually implement them, but if they come up, you'll be a hero rather than a goat because you won't need to make schema changes and all that entails.