Форум сайта python.su
Daevaorn+1 Строем ходить и уставы учить - это полезно ;) А думать надо своей головой (с) (кажется) Троцкий
И строем ходить:-) Заставить всегда можно, но лучше время ожидания сокращать всё-таки.
DaevaornЭто в смысле вместо авторов дернули статьи ? Хм …. Если показываем список авторов IMHO логичнее идти от обратного … + для каждого автора счетчик статей….
Итого N+1 лишних запросов к базе, где N=число статей. Вот вам и ORM. Хорошо, что данная проблема решается штатными средствами, но есть и дуругие, которые не так просто разруливаются.
Офлайн
MaddyА если аторов сотни или тысячи?
Это в смысле вместо авторов дернули статьи ? Хм …. Если показываем список авторов IMHO логичнее идти от обратного … + для каждого автора счетчик статей….
Офлайн
DaevaornНу я ведь и не призываю делать все влоб ;) Я за обход известных граблей топикстартера - сначала встраиваем кучу категорий в Модель, а потом думаем как это объегорить в коде …
Вот видите, уже использование ORM “влоб” порождает проблемы и заставляет задуматься о их решении. А казалось бы, база нормализована и ORM у джанги не плохой по сути…
Офлайн
Если и есть вебе специфика то явно не вопросах работы с БД.
Ведь не только в вебе решаються вопросы высокой производительности. И не все домашние сайты и блоги испытывают колосальные нагрузки.
А что касается вопросов нормализации. Так понятно что гибкость плохо сказывается на производительности.
Денормализация ухудшает гибкость и повышает скорость. Больше гемора в кодинге при этом.
Вообщем это наверное и есть грааль оптимизации. Уменьшайти динамичность и увеличивайте статичность.
Следующий шаг после денормализации. кэширование запросов. следующий кэширование всей страницы целиком.
Короче извечная борьба памяти и процессора. Хочешь выграть в скорости трать больше памяти. Хочешь сэкономить памяти трать больше процессора.
Офлайн