DB / performance: layout of django model that rarely refers to its parent more than once

Question

I have an app that's about presenting fictional simplified cities.

Please consider the following Django models:

class City(models.Model):
    name = models.CharField(...)
    ...

TYPEGROUP_CHOICES = (
    (1, 'basic'),
    (2, 'extra'),
)

class BldgType(models.Model):
    name = models.CharField(...)
    group = models.IntegerField(choices=TYPEGROUP_CHOICES)

class Building(models.Model):
    created_at = models.DateTimeField(...)
    city = models.ForeignKey(City)
    type = models.ForeignKey(BldgType)
    other_criterion = models.ForeignKey(...)

    class Meta:
        get_latest_by = 'created_at'

Explanations for choosing this setup:

(1) Each city has certain buildings of a "basic" type which occur exactly once per city (examples: city hall, fire station, police station, hospital, school) and possibly dozens of buildings of "extra" type, such as dance clubs.

(2) In certain views, all buildings (regardless of city, etc.) are to be filtered according to different criteria, e.g., other_criterion.

Problem/concern:

In a city_detail view, I would have to loop over any buildings of "extra" type, which is OK and normal.

But I am not sure how to efficiently retrieve the city's "hospital" building, which is of "basic" type, so I must do this for every city anyway because exactly one such hospital exists in each city (this is ensured at city creation time).

There will be at most a dozen of "basic" building types, of which about half will be presented all the time.

I'm inclined towards writing convenience methods on the City model, and I face three options:

(A1) Via try and index: .filter(...)[0]

(A2) Via try and .get(...)

(A3) Via try and .filter(...).latest()

But none of those seem elegant. Or is one of these three options good to combine with some sort of caching, like in Django's get_profile() method on the User model? Unfortunately, I have no experience with caching yet.

Is it nuts to use the following option?

(B) specific FKs in the City model, one for each of the most important basic types

Question:

Which option makes sense the most?
Or is the schema generally faulty for this kind of scenario?

Especially regarding DB performance, what do you suggest? Do I need a completely different approach?

Please advise! :)

Thanks in advance!

Answer 1

If a city can have no more than one each of city hall, fire station, police station, hospital, school etc. then I think the most straightforward way to enforce this is to declare each one as a field on the model:

class City(models.Model):
    name = models.CharField(...)
    city_hall = models.ForeignKey(Building)
    fire_station = models.ForeignKey(Building)
    # ... et cetera

If you find this too "messy" in your City model, you might consider having an intermediate CityBuildings model:

class CityBuildings(models.Model):
    city_hall = models.ForeignKey(Building)
    fire_station = models.ForeignKey(Building)
    # ... et cetera

class City(models.Model):
    name = models.CharField(...)
    buildings = models.OneToOneField(CityBuildings)

Then you refer to buildings as, for example, city.buildings.fire_station

These are just suggestions... I am not sure if either way is more "correct"

Answer 2

For anyone who's interested: silly me discovered the existence of the memoization technique, so I will use some form of that applied to (A2), wrapped in as many convenience methods on the City model as I have "basic" building types.

This is at least somewhat less messy than having FKs in two directions and lets the code be more clear about the separation of interests (modelling on one side, performance on the other).

On the quick, I made out two projects to look at for learning and possibly lending stuff or applying directly:

1. django-memoize
2. github.com/husio/django-easycache/

Mayhaps someone will find this useful also.