Go – Django Model Design

database-designdjango

I've previously asked questions for this project, regarding the Django Admin, Inlines, Generics, etc. Thanks again to the people who contributed answers to those. For background, those questions are here:

Django – Designing Model Relationships – Admin interface and Inline

Django Generic Relations with Django Admin

However, I think I should probably review my model again, to make sure it's actually "correct". So the focus here is on database design, I guess.

We have a Django app with several objects – Users (who have a User Profile), Hospitals, Departments, Institutions (i.e. Education Institutions) – all of whom have multiple addresses (or no addresses). It's quite likely many of these will have multiple addresses.

It's also possible that multiple object may have the same address, but this is rare, and I'm happy to have duplication for those instances where it occurs.

Currently, the model is:

class Address(models.Model):
    street_address = models.CharField(max_length=50)
    suburb = models.CharField(max_length=20)
    state = models.CharField(max_length=3, choices=AUSTRALIAN_STATES_CHOICES)
    ...
    content_type = models.ForeignKey(ContentType)
    object_id = models.PositiveIntegerField()
    content_object = generic.GenericForeignKey()
    ...
class Hospital(models.Model):
    name = models.CharField(max_length=20)
    address = generic.GenericRelation(Address)
    ...
class UserProfile(models.Model):
    user = models.ForeignKey(User, unique=True)
    address = generic.GenericRelation(Address)
    ...

Firstly – am I doing it right, with the FK field on each object that has address(es)?

Secondly, is there a better alternative to using Generic Relations for this case, where different objects all have addresses? In the other post, somebody mentioned using abstract classes – I thought of that, but there seems to be quite a bit of duplication there, since the addresses model is basically identical for all.

Also, we'll be heavily using the Django admin, so it has to work with that, preferrably also with address as inlines.(That's where I was hitting an issue – because I was using generic relationships, the Django admin was expecting something in the content_type and object_id fields, and was erroring out when those were empty, instead of giving some kind of lookup).

Cheers,
Victor

Best Answer

I think what you've done is more complicated than using some kind of subclassing (the base class can either be abstract or not).

class Addressable(models.Model):
  ...   # common attributes to all addressable objects

class Hospital(Addressable):
  name = models.CharField(max_length=20)
  ...

class UserProfile(models.Model):
  user = models.ForeignKey(User, unique=True)

class Address(models.Model):
  street_address = models.CharField(max_length=50)
  suburb = models.CharField(max_length=20)
  state = models.CharField(max_length=3, choices=AUSTRALIAN_STATES_CHOICES)
  ...
  owner = models.ForeignKey(Addressable)

You should consider making the base class (Addressable) abstract, if you don't want a seperate table for it in your database.

Related Solutions

R – Django Generic Relations with Django Admin

Using generic relations in django is exactly that. A ForeignKey to ContentType (content_type) and an IntegerField to denote the instance id (object_id). These are useful if you don't know which type of content the ForeignKey is pointing to. Since you know you're targeting the Address model you want to use regular ForeignKey(Address) instead of generic relations.

In response to your comment

Actually its much easier to use ForeignKey since you don't need to go through ContentType.

class Address(models.Model):
  street=models.CharField(max_length=100)
  city=models.CharField(max_length=100)


class Hospital(models.Model):
  name=models.CharField(max_length=100)
  created=models.DateTimeField()
  address=models.ForeignKey(Address, related_name="hospitals")

class Institution(models.Model):
  name=models.CharField(max_length=100)
  address=models.ForeignKey(Address, related_name="institutions")


>>> instance=Institution.objects.get(id=1)
>>> instance.address.city
>>> address=Address.objects.get(id=1)
>>> address.institutions.all() 
>>> address.hospitals.all()

Are your models going to share addresses? i.e. Can a Hospital and an Institution and perhaps a UserProfile all point to the same address instance? Or is it more likely that each will have it's own address? I am trying to understand why you've created a separate class Address. If it's to avoid retyping the same fields into each class you could use an abstract model class and subclass it. Or you might be needing a OneToOneField which is a two way pointer between the two instances.

Python – the difference between null=True and blank=True in Django

null=True sets NULL (versus NOT NULL) on the column in your DB. Blank values for Django field types such as DateTimeField or ForeignKey will be stored as NULL in the DB.

blank determines whether the field will be required in forms. This includes the admin and your custom forms. If blank=True then the field will not be required, whereas if it's False the field cannot be blank.

The combo of the two is so frequent because typically if you're going to allow a field to be blank in your form, you're going to also need your database to allow NULL values for that field. The exception is CharFields and TextFields, which in Django are never saved as NULL. Blank values are stored in the DB as an empty string ('').

A few examples:

models.DateTimeField(blank=True) # raises IntegrityError if blank

models.DateTimeField(null=True) # NULL allowed, but must be filled out in a form

Obviously, Those two options don't make logical sense to use (though there might be a use case for null=True, blank=False if you want a field to always be required in forms, optional when dealing with an object through something like the shell.)

models.CharField(blank=True) # No problem, blank is stored as ''

models.CharField(null=True) # NULL allowed, but will never be set as NULL

CHAR and TEXT types are never saved as NULL by Django, so null=True is unnecessary. However, you can manually set one of these fields to None to force set it as NULL. If you have a scenario where that might be necessary, you should still include null=True.

Best Answer

Related Solutions

R – Django Generic Relations with Django Admin

Python – the difference between null=True and blank=True in Django

Related Topic