2017-02-15 2 views
0

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

Поскольку собранная информация схожа для каждого типа пользователей, я планирую использовать только одну пользовательскую модель с двумя логическими полями для каждого типа пользователя. Модель будет определена следующим образом:

class My_Users(AbstractBaseUser): 
... 
is_active = models.BooleanField(default=True) 
is_admin = models.BooleanField(default=False) 
is_typeA = models.BooleanField(default=False) 
is_typeB = models.BooleanField(default=False) 

... 

Я намерен использовать поля OneToOne на основе идентификаторов пользователей в других моделях, как для TypeA и TypeB пользователей. Так, например, не может быть:

class Model1(models.Model): 
    id = models.OneToOneField(TypeA, on_delete=models.CASCADE, primary_key=True,) 
    ... 

class Model2(models.Model): 
    id = models.OneToOneField(TypeB, on_delete=models.CASCADE, primary_key=True,) 
    ... 

Мой вопрос в следующем:

1/Это будет означать, что некоторые идентификаторы, созданные в моей пользовательской модели будет TypeA и некоторые другие будут TypeB. Будет ли это проблемой для одного-единственного отношения? т.е. будет ли проблема, что идентификаторы не являются инкрементальными (тип A может быть id 1, 3, 4, 5 и т. д., тогда как тип B может иметь идентификаторы 2, 6, 7 и т. д.) для одного к-одному.

2/Это лучший набор, обеспечивающий масштабируемость приложения. Если нет, что бы это было?

Спасибо.

ответ

0
  1. Нет, это не является проблемой для отношений «один-к-одному». Как указано в this SO answer, OneToOne - это просто ForeignKey с уникальным значением = True, а обратное отношение - единственное.

  2. Было бы полезно немного подробнее о том, как вы делите приложение на основе типа пользователя, и что вы подразумеваете под «масштабируемым». Django's Groups and permissions - это более обобщаемое решение для «каждой группы пользователей, имеющей доступ к различным страницам на сайте», а затем вы можете проверить членство в группе, когда вы тоже создаете объекты.

+0

Hi neomanic, спасибо за ваш ответ. Под «масштабируемым» я имею в виду размер пользовательской базы приложения, то есть когда он растет до значительного количества пользователей. Что касается двух типов пользователей, они будут иметь доступ к различным типам функций. TypeA сможет добавлять и управлять объектами на сайте, в то время как TypeB сможет покупать и просматривать. – RobinW2

+0

Итак, у вас есть обычные пользователи и администраторы? Именно там я использую функциональность групп/разрешений в моем webapp. Было бы достаточно просто, чтобы перейти к более простой реализации, основанной исключительно на атрибутах User, если масштабируемость начнет страдать, но я бы не стал беспокоиться об этом в первоначальном дизайне. – neomanic

+0

Большое спасибо за помощь. Я посмотрю немного больше на группы и разрешения и учтем ваш ответ как правильный. – RobinW2

Смежные вопросы