It's perfectly acceptable to store point-in-time values--whole strings!--in your relation model, along side the FK. They actually record different information:

1. the strings are for reconstructing the order as it, at the time it was placed.

2. the FKs are for managing and categorizing the order data, eg: How many orders did customer X place in March? What's the margin on SKU Y? etc. The FKs facilitate this. Update the SKU description, assuming the product is still the same product, and all the data flows through properly to the reports.

Really, the relation model is not optimized for "first-order" applications, such as saving and displaying a complex entity. Document dbs are great at this.

Instead, it's optimized for second and third-order applications, like "show me all the clients that ordered X in March but didn't order Y in April." The whole point of the relation model is to make the data orthogonal to any particular application. Try asking those second-order questions of your document-based DB. Yes, it can be done, but at what effort, and with what degree of confidence in the results? cf. http://howfuckedismydatabase.com/nosql/

EDIT: all that said, I think there really is a benefit to document dbs: maybe you don't care about second order applications yet. Maybe you just need to bang something out today.

Since the relational model is orthogonal to your application, it can be a real bitch to get it "right". How do you know what you will use this data for tomorrow? You don't, you can make some guesses, but this is where the normal forms come in: "follow these rules, and you can use your data for anything!" Well, fine, but the resulting models are often very hard to grok, and hard to work with. For someone w/ better things to do, this can turn into a real time sink.

Perhaps it is better to take on a little technical debt today, with the expectation that tomorrow, if need be, you'll convert or extract to a more relational form.