Eliminating extra DBQueries in django by storing the absolute_url

Using Django blogging, I have a template that looks like:

<a href="{{ post.get_absolute_url }}">{{ post.title }}</a>

This looks innocuous enough, but it ends up generating yet another lookup of the user of the blog post, something that I (in most cases) already know. However that isn't my point.

The URL looks like:

http://localhost:8000/blog/post/mark/2010/08/Aspect-Oriented-Prog/

and part of the reason it looks like that is so that the URL is somewhat self explanatory, and won't change with time.

What I'm very curious about is what are the possible problems with storing this URL in the database along with the blog post? If it isn't supposed to change, and I store it there, then fetching the blog, gives me the absolute_url without having to fetch the user and rebuild the URL.

I'm thinking the part I store does not include /blog/post, but includes the post specific info so that I can do:

{% url blog-post blog %} and have it paste the pieces together.

Just for the record, yes, I could do selected_related, except in my case, I'm actually coming at this backward from an activity log where I'm getting the object like so:

def get_edited_object(self):
    "Returns the edited object represented by this log entry"
    return self.content_type.get_object_for_this_type(pk=self.object_id)

and I haven't figured out how to add the select related to this, but wonder if I need to, given the fact I can add the absolute_url to the object itself.

I realize this is somewhat subjective, but what I really need is som开发者_JS百科eone to play devils advocate for why I shouldn't do this, because it seems to simple and straightforward, I don't see any reason not to.

---

I believe this is a case of normalizing versus denormalizing. The normalizing school would argue that if you have the necessary information to create the URL available in the database then you should be computing it rather than storing and retrieving. Denormalizing would let you get away without computing it each time.

I'll take a stab at playing devil's advocate. I have two arguments.

1. If you decide to change the scheme of your URLs for any reason - say migrating to another top level domain, or changing any element in the path (say "/b" instead of "/blog") then you'd have an unnecessary data migration in your hands.

2. Users are allowed edit the blog posts. If an user changes the title of her blog post then the slug will have to be generated again, which in turn means that the URL would have to be computed and stored again.

3. If the user handle can change (I know this is unlikely, but I have seen sites who let you do this) then you'd have to compute and store again.