You've got a few different questions in here:
Q: It takes a very long time to access the sales of a given store or a given item for any period.
A: To troubleshoot that, we would need to see the execution plans of the queries involved, plus know a little about the query runtime and the hardware involved. 10mm rows in a header table and 110mm rows in a detail table isn't much at all for SQL Server, so this should be a solvable problem.
Q: (Partitioning) worked great for finding the sales of an item. The problem is that many of the reports require the StoreID in addition to being over a specific date range.
A: Correct, partitioning rarely makes SELECT queries faster. It's more about improving performance of bulk loads, specifically partition switching. I wouldn't think of partitioning as a solution to this problem, and indeed, it will actually make most queries worse.
Q: Is there a preferred, correct, standard, etc. method for dealing with tables in the Master/Detail pattern in order to increase performance?
A: Absolutely - archive older data. Figure out what you're going to let users query online at high speed, and then beyond that, move the data into a separate set of archive tables. You can use a partitioned view over the old and new tables in order to give them a single seamless view into the data for easier reporting too.
There's a lot of advantages to this approach. For example, when you want to add additional fields to the current table, you can do that quickly without having to deal with a large amount of archive data. If you want to add lots of indexes to the old archive data, you can - because it's not getting tons of inserts/updates/deletes anymore. If you split the old and new data into different databases, you can even use different backup/recovery strategies with them - even while the view is in place, and users don't know the data is split.
Partitioning could quite possibly help you in this situation. By putting the data into a partition, the database will have a smaller table for each client to deal with. This could help performance a lot.
Here is an example of how it would help. The data in the table would otherwise be interleaved, so different clients would have rows on a data page. Reading the data from a single client would then "clutter up" the available page cache with records from other clients.
However, it will not help very much if all the clients are accessing data concurrently, so all are competing for available memory. Partitioning probably will not make this worse, but it won't necessarily help.
Also, MySQL automatically partitions the indexes on the table, which is generally a good thing.
Often partitioning is applied to a date field, so older data gets put into less used partitions. This may be a case where another field is useful. But, if all the clients need all their data at the same time, then the partitioning may not give you much of a gain.
Best Answer
For an Update to the existing table, one solution would be:
Though, I would also, as Chris Aldrich said in the comments, suggest using a view. That view could be: