Несколько столов или один стол?

Question

Я уже видел несколько форумов с этим вопросом, но они не отвечают на одну вещь, которую я хочу знать. Сначала я объясню свою тему:

У меня есть система, в которой каждый журнал нескольких пользователей заносится в базу данных (например, Пользователь1 вошел в систему, Пользователь2 вошел в систему, Пользователь1 вошел в Управление пользователями, Пользователь2 изменил пароль и т. Д.). Так что я бы ожидал от 100 до 200 записей на пользователя в день. Прямо сейчас я делаю это в одной таблице и для просмотра мне просто нужно отфильтровать, используя UserID.

Мой вопрос: что эффективнее? Должен ли я использовать одну таблицу или создать таблицу для каждого пользователя?

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

Я также хочу знать, какой из них экономит больше места? несколько столов или один стол?

Answer 1

Я бы пошел с одним столом.С индексом userId вы сможете легко масштабировать до миллионов строк без особых проблем.

Таблица на пользователя может быть более эффективной, но, как правило, плохой дизайн.Проблема с таблицей на пользователя в том, что она затрудняет ответы на другие вопросы, такие как «кто вчера был в управлении пользователями?»или «сколько людей изменили свои пароли?»

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

Answer 2

Пока вы используете индексы в полях, из которых вы выбираете, у вас не должно быть проблем со скоростью (хотя индексы замедляют запись, слишком много - плохая вещь).Таблица с несколькими тысячами записей ничего не значит для mySQL (или любого другого механизма базы данных).

Затраты на создание тысяч таблиц намного хуже - скажем, вы хотите внести изменения в поля своего пользователяtable - теперь вам нужно изменить тысячи таблиц.

Таблица, в которой мы регулярно ищем одну запись @ work, содержит около 150 000 строк, а поскольку искомое поле проиндексировано, время поискав очень маленьких долях секунды.

Если вы выбираете эти записи без использования первичного ключа, создайте индекс в поле, которое вы используете для выбора, например:

CREATE INDEX my_column_name ON my_table(my_column_name);

Это самая основная форма.Чтобы узнать больше об этом, отметьте здесь

Answer 3

Любая база данных, достойная своей соли, будет обрабатывать одну таблицу, содержащую всю эту пользовательскую информацию, без проблем. Один стол - определенно правильный способ сделать это.

Если вы использовали несколько таблиц, вам нужно будет создавать новую таблицу каждый раз, когда регистрируется новый пользователь. Вам нужно будет создать новый объект выписки для каждого запрашиваемого пользователя. Это был бы полный беспорядок.

Answer 4

Определенно одна таблица.Наличие таблиц, создаваемых динамически для сущностей, создаваемых приложением, не масштабируется.Кроме того, вам нужно будет создавать запросы с именами таблиц переменных, что затрудняет отладку и обслуживание.Если у вас есть индекс по идентификатору пользователя, который вы используете для фильтрации, для БД не составит большого труда работать с миллионами строк.

Answer 5

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

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

Answer 6

Одиночная таблица приносит эффективность в $ _POST и $ _GET подготовленные операторы PHP. Я думаю, что для малых и средних платформ, один стол будет хорошо. Резюме, несколько таблиц для многих таблиц будет идеальным.

Тем не менее, несколько таблиц также не вызовут большого хаоса. Но лучшее на одном столе.

Answer 7

Я бы тоже пошел за одним столом. Возможно, вы захотите использовать несколько таблиц, когда вы хотите обслуживать нескольких клиентов с разным набором пользователей (многопользовательский режим). В противном случае, если вы используете несколько таблиц, взгляните на этот инструмент рефакторинга: http://www.liquibase.org/. Вы можете вносить изменения схемы на лету.

Полагаю, если вы используете правильную индексацию, то решение с одной таблицей может работать достаточно хорошо (и обслуживание будет намного проще).