Какие требования к бд и архитектуре для такого приложения?

Question

[madc0de]

Доброго временени суток!
Стоить задача сделать сервис для 10 магазинов, в котором будут все товары каждого магазина, больше 10тыс. В нем они будут модерироваться, обновляться из прайс-листов. Некая панель для управления своими интернет магазинами. Магазины будут добавляться. Возможно в будущем создаться платформа и магазины с опенкарта перейдут под эту систему.

Вопрос:
Какую архитектуру базы данных создать, под каждый сайт отдельные таблицы или отдельную базу данных под каждый мгаазин или сотни тысяч товаров в одной держать. Кто работал с конструторами сайтов, какая у них база данных под каждого клиента. И стоит ли вообще использовать mysql или стоит рассмотреть другого вариант? Как бы вы построили базу данных, если бы таких магазинов было 100 и более.

Из себя сервис простой для менеджеров:
Выбрал магазин, видишь список товаров, можешь добавить удалить обновить, нажать чтобы добавился на сайт. И да, на сайт они по апи будут добавляться или yml

Comments

[Иван Шумов]

1. Не корректный заголовок вопроса: архитектура это проектирование будущей системы по бизнес-требованиям. Бд это вообще частное следствие, при чем даже не в первой десятке вопросов.
2. Сначала определитесь с требованиями к системе, моделью данных, из поведением в системе и тому подобными вопросами. Там уже можно будет начать разговор

[alex-1917]

Как бы вы построили базу данных, если бы таких магазинов было 100 и более.

я бы нанял спецов, а не по форумам бегал

[madc0de]

Ты молодец!

Answer 1

[Евгений Вольф]

Вопрос:
Какую архитектуру базы данных создать, под каждый сайт отдельные таблицы или отдельную базу данных под каждый мгаазин или сотни тысяч товаров в одной держать. Кто работал с конструторами сайтов, какая у них база данных под каждого клиента. И стоит ли вообще использовать mysql или стоит рассмотреть другого вариант? Как бы вы построили базу данных, если бы таких магазинов было 100 и более.

С точки зрения логики, безопасности, здравого смысла и ряда прочих факторов, включая архитектурные особенности (по части хранения таблиц в рамках файловой системы) самих БД - я хранил подобные данные в разных БД. Но, с учётом того, что "сотня тысяч" строк, это по большому счёту "пшик" и база уровня "шаред-хостинг" (думаю, ещё даже не VPS) - то для удобства можно хранить всё это и в одной базе.

На счёт стоит ли использовать MySQL - лично Вам, в данный момент - я думаю стоит. Смена одной БД на другую, без полного понимая контекста того, зачем это делается и чем одна отличается от дургой - обычно ничем хорошим не горозит. Движки БД (популярных) сами по себе, "из коробки", друг от друга не слишком сильно отличаются и чудесным образом один из них "по умолчанию" не будет "лучше" чем другой. Я неоднократно работал над проектами где "сотни тысяч" (записей) появлялись ежедневно и они (эти проекты) прекрасно себя чувствовали на MySQL'е.