Могут быть разные подходы к реализации, и каждый из них зависит от природы вашего приложения, например, какие функциональные возможности предоставляются каждому пользователю, какие данные для каждого пользователя задействованы и какие отношения эти данные содержат, сколько данных для каждого пользователя участие и т. д.
Подход 1 : база данных одного приложения; несколько таблиц в соответствии с функциональностью / структурой приложения, но таблицы содержат данные для всех пользователей. Например, comments, permissions, categories и т. Д.
плюсы : простая архитектура, простой и быстрый поиск и вставка
cons : операции с базой данных могут дорого обойтись, если таблицы станут слишком большими по размеру или будут содержать сложные индексы
Подход 2 : база данных для одного приложения; несколько таблиц в соответствии с функциональностью / структурой приложений; каждый пользователь имеет свой собственный набор таблиц, идентифицируемый, возможно, user_id. Например, для user_id = 1 таблицы могут быть comments_1, permissions_1, categories_1 и т. Д.
плюсы : опять простая архитектура; легко определить, какие таблицы запрашивать для конкретного пользователя; поскольку таблицы будут содержать данные только для конкретного пользователя, предложение WHERE будет как минимум на одно меньше меньше (где user_id = xx); меньшие таблицы и, следовательно, более быстрый поиск; меньше шансов на конфликты блокировок в рабочее время
минусы : требуется больше обслуживания; добавление новых функций, для которых требуется добавить новый столбец или таблицу, потребует изменения схемы для всех пользовательских таблиц;
Подход 3 : несколько баз данных приложений на пользователя
плюсы : 100% изоляция данных между пользователями; легко настраивать схему БД, если для пользователя требуется индивидуальная функциональность; легко распределить базы данных по нескольким серверам для балансировки нагрузки;
минусы : сложная архитектура; требует больше обслуживания; сложнее хранить общие или общие данные - данные могут быть либо реплицированы в каждую пользовательскую базу данных, либо может поддерживаться общая база данных.
Я думаю, что если схема эффективно спроектирована таким образом, что поддерживается баланс между более быстрыми SELECT / INSERT и количеством данных в таблице, первый подход должен хорошо работать для 100-10000 пользователей. Однако для этого потребуется большая настройка базы данных и умные индексы.
С подходом 2 и 3 оба отлично работают, но, с моей точки зрения, подход 3 лучше, поскольку он дает вам большую гибкость. Для реализации может потребоваться некоторое время, но это не сложно
Кроме того, SQLite не подходит для такой реализации. Я предложу реляционную базу данных, такую как MySQL.
Надеюсь, что вышеизложенное дает некоторое представление о реализации и помогает вам решить, что лучше всего подходит для вашего приложения.