SQLite: отдельные таблицы для пользователя или одна таблица для них всех?

Question

Я уже создал веб-сайт, который использует базу данных SQLite. Вместо того, чтобы использовать одну большую таблицу, я разработал ее так, чтобы, когда пользователь подписывается, для них создается отдельная таблица. Каждый пользователь может использовать несколько сотен записей. Я сделал это, потому что думал, что будет проще структурировать и получить доступ.

Я нашел по другим вопросам на этом сайте, что один стол лучше, чем использование многих таблиц для каждого пользователя.

Стоит ли перепроектировать мой сайт, чтобы вместо большого количества таблиц была бы одна большая таблица? Текущий метод мой, кажется, работает хорошо, хотя он все еще находится в разработке, поэтому я не уверен, насколько он будет складываться в реальной среде.

Вопрос заключается в следующем: изменил бы код, чтобы одна большая база данных, а не многие отдельные, стоила того с точки зрения производительности, эффективности, организации и пространства?

SQLite: создание таблицы пользователя.

CREATE TABLE " + name + " (id INTEGER PRIMARY KEY, subject TEXT, topic TEXT, questionNumber INTEGER, question TEXT, answer TEXT, color TEXT) 

SQLite: Добавление учетной записи в таблице счетов.

"INSERT INTO accounts (name, email, password, activated) VALUES (?,?,?,?)", (name, email, password, activated,) 

Пожалуйста, обратите внимание, что я использую питон с Колбой, если это делает никакой разницы.

---

EDIT

Я также знаю, что есть вопросы, как это уже, однако ни одно государство ли преимущества или недостатки будет стоит.

Answer 1

На объектно-ориентированном языке вы бы создали класс для каждого пользователя? Или у вас есть экземпляр класса для каждого пользователя?

Наличие одной таблицы для пользователя - очень плохой дизайн.

• Вы не можете искать сообщения на основе любого поля, которое не является именем пользователя. С вашим текущим решением, как вы найдете все сообщения для определенного questionNumber?
• Вы не можете присоединиться к таблицам сообщений. Вы должны сделать два запроса: один, чтобы найти имя таблицы и один, чтобы фактически запросить таблицу, что требует двух обращений к серверу базы данных.
• У каждого пользователя теперь есть своя таблица. При обновлении вам необходимо применить миграцию схемы к каждой таблице сообщений, и Бог поможет вам, если некоторые из таблиц несовместимы с остальными.
• Фактически невозможно иметь внешние ключи, указывающие на таблицу сообщений. Вы не можете указать таблицу, на которую указывает столбец внешнего ключа, потому что она не будет одинаковой.
• У вас может быть конфликт имен с вашей текущей настройкой. Что делать, если кто-то регистрируется с именем пользователя accounts? По общему признанию, это легко исправить, добавив префикс user_, но все же что-то нужно иметь в виду.
• Уязвимости от SQL-инъекций. Что делать, если я зарегистрирую пользователя с именем lol; DROP TABLE accounts; --? Параметры запроса, основной способ предотвращения таких атак, не работают с именами таблиц.

Я мог бы продолжить.

Пожалуйста, объедините все таблицы и прочитайте нормализацию базы данных.