Re: Different auth user models withoout doing multi-table inheritance

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVyNVxAAoJEC0ft5FqUuEhpa8P/2rvwljsL8aZKeW2VzK2aD9x
qy41u/qC0mctlnXZDaAYCn9bN0+ZbHItKMR74tyylohM56MsNO6P+EchO+I4RoQB
tXlYnfk+ohGzjIeon4dpzhKOonMrFP1CqfqpKWkGP1/PowmsDGl3bZ06b4/wsG3y
WW2mz0Sy2yoKfGnobclRB7wdL2om5sFo6v0y+Q4B5fgsGwgHDdkfm2NCVJlyED+s
VqS6ifrZgc53zA+sujz4gLOlOjc05GF1dNS3CPodV2A9Ea8h75rhf/Pn/h3ZJuFd
3VbMtpMoqYzD1cfrHQZ76oKSOPwqOzxrgOMfFzX7mZNxF1sMqWLXDNKOW1TMB++/
i2IaEBsq7QCk6aO0SoFHJHTvPpqgrmXrAUErmwFz9i6tsZUYwZDXReS3YDFgpq4I
mma0FfHxRIh3Od+FxgD3iGlykM7LTm9n3WmrzwpISzEom12KslcSKOVg58guqLjg
bt7OJpC+8y8FQA8jT4dBAilx6z0baSR1H3JQ4NyiNi3MWtsdYh/TI7Taj8nszQqB
L5MxUFC02jLB+22qT7Pu9bv0b1Cvk+0iRI5q52VyvmmTwAZHHaptGngBUG0c6T9b
ZjTnEj31QZQOTqHkbV0UaswIq+DFws8Ld7l4TqaslkV9+/DXEgw5fuo8ih0ND39K
bdj0XA7x2YAilCNUOQI3
=kNgq
-----END PGP SIGNATURE-----
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+unsubscribe@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.