Вы не дали слишком много подробностей (что затрудняет предоставление хорошего ответа), хотя слова, которые вы выбрали для использования в своем вопросе, наводят меня на мысль, что это одно приложение с разными "скинами".
На моем сайте будет доступно много продуктов, но они будут распределены по категориям на совершенно разные сайты (домены).
Я предполагаю, что у вас будет один интернет-магазин с несколькими различными магазинами: cool-widgets.com, awesome-sprockets.com, neato-things.com и т. Д. Все они будут одинаковыми, за исключением, возможно, CSS-скин или что-то простое в этом роде. Все вещи администратора магазина будут выполнены в какой-то центральной системе, а доменное имя будет просто действовать как имя категории.
Таким образом, разделение одних и тех же данных на два разных контейнера по произвольному критерию (category_name == 'cool-widges.com') - это разбиение данных , что является анти-паттерном. Точно так же, как у вас не будет двух разных пользовательских таблиц, основанных на имени пользователя ([Users $ A-to-M] и [Users $ N-to-Z]), не имеет смысла иметь две разные таблицы (или базы данных). ) для названий категорий.
Существует и будет много общего кода между категориями: управление пользователями, администратор, обработка заказов, импорт данных и т. Д. Объединить несколько хранилищ данных в общий код будет гораздо сложнее, чем будет. для разделения категорий в магазине отображать код. Кроме того, ошибки сегрегации будут гораздо более очевидными: на странице сравнения цен показаны товары из всех трех магазинов. Ошибки агрегации будут намного меньше: только три из четырех магазинов были обновлены. Вот почему это анти-паттерн.
Примечание: да, перед тем, как вы скажете, что портирование данных имеет свои применения (что оно и делает), эти применения появляются в намного позже, чем возникают проблемы с производительностью. Многие серьезные платформы баз данных допускают закулисное разделение, чтобы не создавать глупую модель данных.