Database design for articles with localized prices
I would have tables for:

Supplier

Product

Inventory

Price

Currency

Sales

Country


I would follow tradional Entity Relationship Diagram and model. The more you normalise the design the more efficient it will be because it will be doing less IO. Sometimes you can take shortcuts which might save you a bit of time. But eventually it'll catch up with you and you'll wish you did it properly the first time.
A product could have many prices. Could be sold in many countries. Some countries could have multiple currencies. Prices change over time.
If you expect there will be more than 1 country/currency/price etc then design it to handle multiple countries/currencies/prices etc from the beggining.
So when you define a price you'd want to be able to define a price for this product, in this country, in this currency for this time frame.
Yes its possible to combine all of these things into a compound key, but experience has taught me you dont want keys to have any business meaning.
&quot;Performance&quot; is relative. RDBMs' are extremely good at crunching transactional data. With good design this model will scale up to corporate levels. Reporting and analytics might need a rethink.