Does partitioning sometimes require denormalization? Specific example of what I'm asking:

Say that a SaaS app has an Order table with CustomerID and a child OrderItem table.

We want to partition both tables and we want to use CustomerID as the partition key.

The issue is that the OrderItem table does not have a CustomerID column (its only foreign key is to the Order table).

Would it be a best-practice to denormalize the OrderItem table and add a CustomerID column to it for the sake of partitioning?
Yes, if you want to partition by CustomerID, then CustomerID must exist in the table (even if it is redundant).

But first, IMHO, you need to ask yourself a couple of questions:


Do I need partitioning? What am I using it for? What problem am I solving?
If the answer to 1. is yes, then am I partitioning on the right column? How - specifically - will partitioning on CustomerID help in my environment?


I find that a lot of people turn to partitioning as a knee-jerk reaction to a performance problem of some kind that partitioning simply can't (completely) solve. 

Similar to indexed views - people create views on top of views on top of views, then assume that all they need to do is create an index on each view and that will speed everything up. Then they actually learn the hard way about what indexed views are, how they work, and the much more limited set of scenarios that comprise their "sweet spot."