Сергей Протасов

ничего не нужно выдумывать. Обычный селектор по атрибуту. И работает он так же как и все остальные селекторы по скорости (если конечно вы не про ie7 какой-нибудь). Скорость работы селектора равноценна его специфичности. Скажем селектор #dataset [data-toggle] будет работать медленнее чем #dataset > [data-toggle] или же просто [data-toggle]. Селекторы все же с права на лево обрабатываются. И да, так мы жестко даем понять что мы должны добавить атрибут а не через метод $.fn.data назначить что-то.

Вполне нормальный селектор, только контекст добавить не мешало бы и использовать $.fn.children (если задача/разметка позволяет):

var $item = $('#dataset').children('[data-id="'+id+'"]');

статик - контент, который относиться к фреймворку и тому что написано на нем
https://docs.djangoproject.com/en/1.9/howto/static...

{% load staticfiles %}
<img src="{% static "my_app/myexample.jpg" %}" alt="My image"/>

медиа - контент, который сгенерировал в ходе работы приложения. ЕГо могли сгенерировать пользователи, админы и тд

Линки на медиа файлы делаются еще проще

{{ mymodel.my_image_field.url }}

Что является более грамотным - довольно скользкая тема.
Более правильное академически - нормальные формы и т.п.?
На практике частенько приходится отходить от норм реляционной теории данных. Например, дублировать данные, чтобы местами избежать джойнов в запросах, которые будут выполняться очень часто.

Если комментарии и к вопросам и к ответам - одинаковая сущность, то я бы сделал их одной таблицей. И в ней 2 поля (помимо прочих):
question_id - связь с вопросом; всегда существует.
answer_id - связь с ответом; NULL если был прокомментирован именно вопрос.
Таким образом, мы можем запрашивать комментарии без необходимости джойнить таблицы, как ко всему вопросу и его ответам, так и отдельно к вопросу, и к конкретному ответу на вопрос.