Устранение лишних DBQueries в django путем сохранения absolute_url

Question

Используя блоггинг Django, у меня есть шаблон, который выглядит следующим образом:

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

Это выглядит достаточно безобидно, но в итоге генерируется еще один поиск пользователя в блоге, что-то, что я (вбольшинство случаев) уже известно.Однако это не моя точка зрения.

URL выглядит следующим образом:

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

, и отчасти причина, по которой он выглядит так, заключается в том, что URL несколько понятен и выиграл 't меняются со временем.

Что меня очень интересует, так это возможные проблемы с сохранением этого URL в базе данных вместе с постом в блоге?Если он не должен меняться, и я храню его там, то при извлечении блога я получаю absolute_url без необходимости извлекать пользователя и перестраивать URL.

Я думаю, что часть, которую я храню, делаетне включает / blog / post, но включает в себя информацию, относящуюся к сообщению, так что я могу сделать:

{% url blog-post blog%} и сделать так, чтобы части были вставлены вместе.

Только длязапись, да, я мог бы сделать selected_related, кроме как в моем случае, я на самом деле возвращаюсь к этому назад из журнала активности, где я получаю объект следующим образом:

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)

и у меня нет 'Я не могу понять, как добавить к этому отношение select, но задаюсь вопросом, нужно ли мне это, учитывая тот факт, что я могу добавить absolute_url к самому объекту.

Я понимаю, что это несколько субъективно, но то, что мне действительно нужноКто-то, кто играет дьяволов, защищает то, почему я не должен этого делать, потому что это кажется простым и понятным, я не вижу причин, чтобы этого не делать.

Answer 1

Я считаю, что это случай нормализации по сравнению с денормализацией. Нормализующая школа будет утверждать, что если у вас есть необходимая информация для создания URL-адреса, доступного в базе данных, вы должны ее вычислять, а не хранить и извлекать. Денормализация позволит вам уйти, не вычисляя его каждый раз.

Я попробую сыграть адвоката дьявола. У меня есть два аргумента.

1. Если вы по какой-либо причине решите изменить схему своих URL-адресов - скажем, переход на другой домен верхнего уровня или изменение любого элемента в пути (например, «/ b» вместо «/ blog»), тогда вы в ваших руках ненужная миграция данных.

2. Пользователи могут редактировать сообщения в блоге. Если пользователь изменяет заголовок своего поста в блоге, тогда необходимо будет снова создать слаг, что, в свою очередь, означает, что URL придется вычислять и снова сохранять.

3. Если дескриптор пользователя может измениться (я знаю, что это маловероятно, но я видел сайты, которые позволяют вам это делать), то вам придется вычислять и сохранять снова.