Hello Ankit, On 08/10/2015 09:38 AM, Ankit Agrawal wrote: > I am working on a project which has two different sets of users - > |Customer| and |Merchant|. Both of these users should be able to > register and login to their respective profiles. The most obvious choice > to implement this that came to my mind was to make two different models > |Customer| and |Merchant| that inherit from a BaseUser model that will > store the common fields i.e. Multi-table inheritance - > https://docs.djangoproject.com/en/1.8/topics/db/models/#multi-table-inheritance > > > Quoting |Two Scoops of Django| - > > > |At all costs, everyone should avoid multi-table inheritance (see warning > above) since it adds both confusion and substantial overhead... > Adds substantial overhead since each query on a child table requires joins > with all parent tables. > > | > > I would like to know if and why having an explicit |OneToOneField| is > better than Multi-table inheritance.
In terms of the underlying database schema (and thus query efficiency), a OneToOneField is exactly the same as MTI (MTI uses a OneToOneField internally). Personally, I agree with the _Two Scoops_ authors that the explicit OneToOneField is preferable, because it means the ORM objects more closely map to the actual database schema, making it easier to understand what is actually happening at the database level. An explicit OneToOneField also gives you more flexibility in several ways - you can create / delete the base User instance and the linked CustomerProfile / MerchantProfile instances separately from each other, and you can even have a single User instance with both a CustomerProfile and a MerchantProfile (though that may not be useful for your case). > Also, are there any other better > ways to model the above relationship? That depends on how much different information you need to store about customers vs merchants. Assuming it's significant, I think a common User model with OneToOne-linked CustomerProfile and MerchantProfile is probably best (I'm doing the same thing in my current project in a similar situation). I also recommend having a `role` or similar field on the User model, with 'merchant' and 'customer' as choices. This means you can know what type of user a given user is while querying only the User table (so you know which profile table to query for that user), and it also means that you can have users with a known role who haven't created their profile yet (this may or may not be useful for your application, depending how/when profiles are created). Carl -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/55C8D571.8010102%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
