0

Я в настоящее время использую Django 1.5.1 и используя пользовательский пользователь, как описано в официальной документации. Я понял, что все хранится под одним столом, auth_user.Пользовательский пользователь Django пользовательский пользователь VS

Вопрос в том, почему лучше иметь все в одной большой таблице, вместо того, чтобы иметь 2 таблицы, как раньше, до 1,5, используя таблицу user_profile для всех дополнительных данных? Это кажется более умным, как раньше, если мы хотим добавить 20 новых полей для информации о пользователе, странно иметь все в auth_user.

В моем случае, на данный момент у меня есть class MyUser(AbstractUser) с 2 дополнительные поля gender и date_of_birth, так что все хорошо с этим, но сейчас я хотел бы иметь много другой информации (текстовые поля), как «любимые фильмы», «любимый книги "," хобби "," 5 вещей, которые я не мог бы жить без "и т. д. и т. д., чтобы иметь больше информации о моем пользователе. Поэтому мне было просто интересно, следует ли мне поставить класс под MyUser, или мне нужно определить номер UserProfile? И почему?

Спасибо!

ответ

1

Когда у вас есть все в одной таблице, доступ к базе данных происходит быстрее. По старому пути вам понадобилось join на вспомогательной таблице, чтобы получить всю информацию о пользователе.

Обычно, когда вы видите отношение One-to-One, было бы лучше просто объединить их в один стол.

Но новая пользовательская модель User решает также еще одну проблему: какие атрибуты пользователь должен иметь? Какие атрибуты необходимы для вашего приложения? Требуется ли электронное письмо? Должно ли электронное письмо также быть именем пользователя, с которым пользователь входит в систему?

Вы не могли бы сделать это, прежде чем эта функция была введена.

Что касается вашего вопроса о том, где добавить дополнительную информацию о пользователе, например «хобби» и т. Д., Это действительно зависит от того, как часто вы будете запрашивать/нуждаться в этих атрибутах. Они будут только на странице профиля пользователя? Хорошо, тогда вы могли бы иметь их в отдельном столе и не было бы много проблем или производительности. В противном случае предпочитаете хранить их в том же столе, что и User.

+0

Хорошо, спасибо за объяснение. На данный момент я использую имя пользователя как основное обязательное поле, а не адрес электронной почты. Но для входа в систему я создал пользовательский EmailBackend, чтобы проверить как имя пользователя, так и адрес электронной почты, чтобы иметь возможность использовать оба при аутентификации. Но я ясно понимаю, почему этот пользовательский пользователь помогает здесь, это действительно приятно. – Dachmt

+0

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

+0

@ Dachmt Ну, например, в таком месте, как здесь, я бы сохранил их в отдельной таблице. В вашей ситуации это зависит. Могут ли «любимые фильмы» быть денормализированы в каждой таблице, чтобы избежать дублирования? Включит ли это участие пользователей в рейтинге своих фильмов? Тогда, вероятно, да. Но это зависит от функции каждого из этих атрибутов. Если бы у меня был несколько определенный набор полуинформационных атрибутов, которые не выходят за рамки 20-30, я бы поставил их в одну и ту же таблицу. – rantanplan