One product multiple markets database design

Question

Having an abstract task at this point of time:

We have a list of products for country A and a list of products for country B, they sometimes are the same, sometimes products from country A are different to what is offered in country B.

So my current task is to create and elaborate on multiple solutions for database design. Definitely to make it scalable for 17,000 - 1,000,000 products in the future.

What should be taken into consideration when developing the products database?

Few thoughts are:

=> A product table should be specific for each market, for example AUSTRALIAN_PRODUCTS, US_PRODUCTS, where id of a product is a unique identifier

=> To have an multiple schemas for each market

=> To have multiple database instances for each market

Answer 1

When you say "multiple schemas" or "multiple DB instances", I think you mean "unique per country". I would avoid that as very complex long term. Assuming that the same product_id might occur for different products in two different countries, I think you will find that keeping to a single DB with a combined, unique key of country_code, product_id would be most flexible in the long run.

Answer 2

Few remarks

Few thoughts are:
A product table should be specific for each market, for example AUSTRALIAN_PRODUCTS, US_PRODUCTS, where id of a product is a unique identifier

I wouldn't to do such a thing. A basic normalization, will bring a structure of tables like

• Country
• Product
• CountryProduct

To have an multiple schemas for each market

The only benefit for this approach would be for security, different schema in a case like this will isolate one country from another, I don't see why you should go for this approach

To have multiple database instances for each market

same as 2nd option, multiple databases instances would only bring isolation, with no benefits over performance or other things. the only benefit you could have later on, is that you could take one database out of one server and move to another for scalability.