DDwrt100, Бобби Шифер, Прошу меня простить за не совсем конкретное изложение вопроса. Раз такие споры разродились. Просто писал я сервис под один аккаунт. Представьте. Есть одна бд (ранее я использовал SQLite) и к ней могут подключаться пользователи, допустим до 50 человек, но эта бд содержит информацию и бизнес процессы одной организации. И это нормально работает. Затем я стал масштабировать ее на несколько аккаунтов, чтобы зарегистрированные пользователи могли создавать свои аккаунты и приглашать туда пользователей для работы. И здесь возник вопрос как лучше организовать архитектуру бд при том, что структура таблиц для аккаунтов идентична. Вот в этом и состоял мой вопрос. Что касается системной бд которая хранит пользователей, аккаунты и прочие общие веще, все это находится в другой базе данным, здесь стоит вопрос лишь об клиентский данных, как их лучше организовать. Но все равно я много почерпнул из вашего диалога. Спасибо!
Здесь имеется ввиду, что для каждого аккаунта создавать отдельную базу данных и уже админ этого аккаунта будет устанавливать отдельные права для получения информации хранящейся в этом аккаунте для пользователей. Вот регистрирует пользователь аккаунт на сервисе, сервер проверяет имя аккаунта на уникальность, и если все ок, то создается отдельная база данных и туда уже можно будет запускать пользователей с расписанными правами доступа к этой бд. Затем создает другой аккаунт, сервер создает еще одну бд с идентичной структурой. И т.д. Короче сколько аккаунтов столько и бд.
Akina, Я наверное не совсем понятно написал вопрос, но все вопросы которые вы мне задаете в комментарии именно на них я и хочу получит ответ. А что касается многопользовательского - это значит, что много аккаунтов каждый из которых содержит одинаковую структуру для хранения на сервере. И к этим данным (назовём их аккаунтами) будут обращаться пользователи в рамках прав, предоставленных админом клиентской части. Вот как-то так. И вопрос, как лучше выстроить структуру бд.
