Django views - optimum query set in a ForeignKey model

Having the model:

class Notebook(models.Model):
    n_id = models.AutoField(primary_key = True)

class Note(models.Model):
    b_nbook = models.ForeignKey(Notebook)

t开发者_开发技巧he URL pattern passing one parameter:

(r'^(?P<n_id>\d+)/$', 'notebook_notes')

and the following view:

def notebook_notes(request, n_id):
    nbook = get_object_or_404(Nbook, pk=n_id)
...

which of the following is the optimum query set, and why? (they both work and pass the notes based to a selected by URL notebook)

notes = nbook.note_set.filter(b_nbook = n_id)
notes = Note.objects.select_related().filter(b_nbook = n_id)

Well you're comparing apples and oranges a bit there. They may return virtually the same, but you're doing different things on both.

Let's take the relational version first. That query is saying get all the notes that belong to nbook. You're then filtering that queryset by only notes that belong to nbook. You're filtering it twice on the same criteria, in effect. Since Django's querysets are lazy, it doesn't really do anything bad, like hit the database multiple times, but it's still unnecessary.

Now, the second version. Here, you're starting with all notes and filtering to just those that belong to the particular notebook. There's only one filter this time, but it's bad form to do it this way. Since it's a relation, you should look it up through the relational format, i.e. nbook.note_set.all(). On this version, though, you're also using select_related(), which wasn't used on the other version.

select_related will attempt to create a join table with any other relations on the model, in this case a Note. However, since the only relation on Note is Notebook and you already have the notebook, it's redundant.

Taking out all the redundancy in those two version leaves you with just:

notes = nbook.note_set.all()

That, too, will return exactly the same results as the other two version, but is much cleaner and standardized.