Какую архитектуру бд выбрать для приложения с большим количеством аккаунтов?
Добрый вечер!
Есть web приложение, у него база данных, в котором есть таблица зарегистрированных аккаунтов. К каждому аккаунту привязан свой набор данных- юзеры, задачи, товары, платежи и прочее, около 15 таблиц.
Вопрос относительно архитектуры - в данном случае, будет ли правильно хранить данные, связанные с аккаунтами, в одних и тех же таблицах, или же лучше для каждого аккаунта создавать отдельный набор таблиц в пределах одной базы данных?
Иными словами, что лучше- иметь в одной базе данных 15 таблиц - задачи, товары, платежы и т.п по 100.000 записей в каждой, или иметь 1500 таблиц по 1000 записей в каждой?
Как пример именования таблиц: _<имя таблицы>
1_users
1_payments
1_products
2_users
2_payments
2_products и т.д.
> лучше для каждого аккаунта создавать отдельный набор таблиц в пределах одной базы данных?
Вам бы про нормализацию и нормальные формы БД почитать. По всем канонам, то что вы предлагаете - ересь.
А что касается задачи, возможно, вам стоит смотреть в сторону NoSQL-баз
В данном случае мысль именовать таблицы таким образом (с id аккаунта) была не с целью заменить реляционные таблицы, а с тем, чтобы распределить количество записей более равномерно, а не 100500+ в одной таблице (возможно это плохой подход).
Такую идею подсмотрел из архитектуры мультисайта wordpress , там именно так для каждого сайта строятся таблицы:
prefix_site id_имя
Плодить таблицы безусловно плохой путь. НФ "наше" все если используется РСУБД.
Но если НФ незнакомо, то можно подумать о будущих отчетах- например о количестве проданных товаров. Собрать по 100500 таблицам будет тяжелее, чем простым select по двум-трем таблицам.
Простой
