3

I have some fields on a model that won't always be filled in (e.g., the actual completion date and costs until the project is over). Because of this, I thought I'd split the model into two:

  1. Model #1: Dense table containing frequently searched and always completed fields
  2. Model #2: Sparse table containing infrequently searched and not always completed fields

Questions

  1. Am I thinking correctly in splitting this into two models/tables?
  2. Should I use Django's Multi-table Inheritance, or should I explicitly define a OneToOneField? Why?

Configuration

  • Django version 1.3.1

Models

Using Django's Multi-table Inheritance

class Project(models.Model):
    project_number = models.SlugField(max_length=5, blank=False,
            primary_key=True)
    budgeted_costs = models.DecimalField(max_digits=10, decimal_places=2)

class ProjectExtendedInformation(Project):
    submitted_on = models.DateField(auto_now_add=True)
    actual_completion_date = models.DateField(blank=True, null=True)
    actual_project_costs = models.DecimalField(max_digits=10, decimal_places=2,
            blank=True, null=True)

Using an Explicit OneToOneField

class Project(models.Model):
    project_number = models.SlugField(max_length=5, blank=False,
            primary_key=True)
    budgeted_costs = models.DecimalField(max_digits=10, decimal_places=2)

class ProjectExtendedInformation(models.Model):
    project = models.OneToOneField(CapExProject, primary_key=True)
    submitted_on = models.DateField(auto_now_add=True)
    actual_completion_date = models.DateField(blank=True, null=True)
    actual_project_costs = models.DecimalField(max_digits=10, decimal_places=2,
            blank=True, null=True)
Dan Hanly
  • 7,829
  • 13
  • 73
  • 134
Matthew Rankin
  • 457,139
  • 39
  • 126
  • 163
  • Honestly, I don't think splitting your model makes sense, and here's the reason why: You state that the infrequently searched and not always completed fields is also "sparse". That decreases the value of splitting the models, probably to the point that it doesn't make up for the extra complexity. Of course, you know your data better than I do, so take my advice with a grain of salt. – Luke Sneeringer Sep 23 '11 at 16:25

1 Answers1

3

You're essentially dealing with apples and apples here. Django's implementation of MTI (multi-table inheritance) uses an implicit OneToOneField.

Chris Pratt
  • 232,153
  • 36
  • 385
  • 444
  • If this is apples and apples, is one more preferred than another? – Matthew Rankin Oct 13 '11 at 22:15
  • 3
    It depends on the situation. If there's a clear is-a relationship going on. Like `class Dog(Animal)`, then you should use MTI (If it's called for. Some other form of inheritance may be more appropriate). But, in the case of something like `auth.User`, a `UserProfile` is not really a type of `User`, so `OneToOneField` makes more sense. However, the BIG caveat there is that `UserProfile` is used because `User` cannot be altered. Otherwise, simply adding additional fields to `User` would be more appropriate. – Chris Pratt Oct 14 '11 at 14:42