Дизайн базы данных одного продукта для нескольких рынков

Когда вы говорите «несколько схем» или «несколько экземпляров БД», я думаю, вы имеете в виду «уникальные для каждой страны». Я бы избегал этого как очень сложного в долгосрочной перспективе. Предполагая, что один и тот же product_id может встречаться для разных продуктов в двух разных странах, я думаю, вы обнаружите, что сохранение одной БД с комбинированным уникальным ключом country_code, product_id будет наиболее гибким в долгосрочной перспективе.

Несколько замечаний

Несколько соображений:
Таблица продуктов должна быть специфичной для каждого рынка, например AUSTRALIAN_PRODUCTS, US_PRODUCTS, где id продукта – это уникальный идентификатор.

Я бы не стал делать такую ​​вещь. Базовая нормализация принесет структуру таблиц, например

• Страна
• Товар
• СтранаПродукт

Иметь несколько схем для каждого рынка

Единственным преимуществом этого подхода будет безопасность, другая схема в таком случае изолирует одну страну от другой, я не понимаю, почему вы должны использовать этот подход.

Иметь несколько экземпляров базы данных для каждого рынка

так же, как и во втором варианте, несколько экземпляров баз данных принесут только изоляцию, без каких-либо преимуществ по сравнению с производительностью или другими вещами. единственное преимущество, которое вы могли бы получить позже, заключается в том, что вы можете взять одну базу данных с одного сервера и перенести ее на другой для обеспечения масштабируемости.