0

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. Also, are there any other better ways to model the above relationship?

anon
  • 1,069
  • 1
  • 12
  • 17
  • possible duplicate of [Should I avoid multi-table (concrete) inheritance in Django by any means?](http://stackoverflow.com/questions/23466577/should-i-avoid-multi-table-concrete-inheritance-in-django-by-any-means) – MatsLindh Aug 10 '15 at 13:46
  • @MatsLindh: I checked out that SO question already. The answer did not explain why explicit `OneToOneField` does not suffer from the overhead because of JOINS. – anon Aug 10 '15 at 13:51
  • 1
    `OneToOneField` is exactly the same as multi-table inheritance in terms of joins (multi-table inheritance is implemented by a OneToOne field). I believe what Two Scoops of Django are suggesting is that wherever possible you should use abstract base models with a single concrete model... rather than concrete models inheriting from other concrete models via MTI. In the case of the Django auth user model this is not possible because Django can only have one user model, so you need to either put _all_ the fields for both user types on one model or live with multiple inheritance. – Anentropic Aug 10 '15 at 14:11

0 Answers0