Это хорошая практика для автоматического создания таблиц в базе данных, когда пользователь регистрируется?

Question

Я делаю свой первый сайт с Django, и у меня возникла проблема с дизайном базы данных.

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

table: $USERNAME$

id  |  some_data  |  some_more  |  even_more

или имеет одну массивную таблицу с самого начала, с данными каждого в:

table: user_history

id  |  username  |  some_data  |  some_more  |  even_more

Я знаю, как это сделатьвторой, просто объявите это в моих моделях Django.Если я должен сделать первый, как я могу в Django?

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

Второй, кажется, больше соответствует философии дизайна Django (из того, что я видел до сих пор), и было бы проще проводить сравнительный поиск между пользователями, но мог бы получить огромный (количество пользователей * средние элементыв истории).Может ли MySQL обрабатывать, скажем, 1 миллиард записей?(Я не получу это, но хорошо планировать заранее)

Answer 1

Определенно, второй формат - это путь, по которому вы хотите идти.MySQL довольно хорошо справляется с обработкой большого количества строк (конечно, при условии, что они проиндексированы и кэшированы соответствующим образом).Например, все версии всех страниц в Википедии хранятся в одной таблице в их базе данных, и это прекрасно работает.

Answer 2

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

С уважением.

Answer 3

Вы обязательно должны хранить всех пользователей в одной таблице, по одной строке на пользователя.Это единственный способ отфильтровать данные с помощью предложения WHERE.И я не уверен, что MySQL может обрабатывать 1 миллиард записей, но я никогда не считал ограничение количества записей ограничивающим фактором.На данный момент я не буду беспокоиться об ограничении записей.

Answer 4

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

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

table: User
Id | UserName | Password | other data

table: User_history
Id | some_data | timestamp

Нет необходимости беспокоиться о скорости вашей базы данных, если вы определяете правильные индексы для полей, которые вы планируете искать. Использование этих индексов определенно ускорит ваше время отклика, поскольку в вашу таблицу будет добавлено больше записей. База данных, над которой я работаю, содержит несколько таблиц с более чем 30 000 000 записей, и замедления нет.

Answer 5

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

Также имейте в виду, что даже гениальные парни в твиттере / fb / etc не знали, с какими проблемами они столкнутся через некоторое время. И вы тоже не узнаете. Решение проблем с нагрузкой / масштабируемостью и их прогнозирование - своего рода ракетостроение.

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

Answer 6

Все отметили, что второй вариант - это путь, я добавлю к этому свой + 1 .

По поводу первого варианта, в Django вы создаете таблицыобъявив подклассы django.models.Model, а затем при запуске команды управления syncdb он будет просматривать все модели и создавать недостающие таблицы для всех «управляемых» моделей.Может быть возможно вызвать это поведение во время выполнения, но это не так, как все делается.

Answer 7

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

Answer 8

Определенно НЕ создавайте ТАБЛИЦУ для каждого пользователя. Создайте строку для пользователя и, возможно, строку для пользователя и таблицы меньшего размера, если некоторые данные могут быть разложены.