Информация о рубриках хранится в базе. Но на ее основе генерится php-файл. Примерно такой:
$dir[’news’][’id’]=’1’;
$dir[’news’][’name’]=’новости’;
$dir[’news/world’][’id’]=’2’;
$dir[’news/world’][’name’]=’мир’;
$dir[’news/world/iraq’][’id’]=’3’;
$dir[’news/world/iraq’][’name’]=’Ирак’;
Когда нужно разобрать УРЛ, типа news/world/iraq, он прогоняется через массив $dir 3 раза. После этого получаем id рубрики вместе с id подрубрик и их русские названия. (новости/мир/Ирак). В противном случае пришлось бы делать 3 обращения к БД, а так — ни одного. Так что при загрузке каждой страницы лишних 1-3 обращений к базе... Это некузяво.
А чем этот не нравится?
Именно для каждой заметки такое использовать, наверное, не надо. Я использую только для рубрик, так как рубрик мало, и меняются они редко. Причем у меня ДВА массива — один для разбора url -> id, второй — для id -> url.
У меня (spectator.ru) сделано так:
Когда надо получить url документа(ов) с помощью какой-то выборки, из базы документов считываются поля url и dir, где url — это «конец урла», то есть самый последний параметр, а dir — это id директории.
Ну и массив dirn (для разбора id -> url), имеет вид
$dirn['71']='technology/software/games';
$dirn['91']='technology/software/games/english_reviews';
После чего $url = $dirn[$dir].$url
Например, spectator.ru/technology/software/games/dice
url — dice [index]
dir — 71 (technology/software/games) [index]
Ну и, естественно, url — это index. Благо, что он короткий.
Короче, этот способ я использую только для того, чтобы не дергать базу во время любых операций с рубриками.
Ну, у меня есть и эта штука и кэширование на всякий случай. Все-таки лишняя оптимизация не помешает, не надо все валить на кэширование.
На nudnik-е я вообще не стал кэширование делать, кстати.
Ну, чисто теоретически можно сделать так: помимо таблицы связи ключевых слов вида id поста — id ключевого слова можно хранить избыточную информацию в таблице постов. Например, keywords (varchar), а там id ключевых слов в виде «1,3,5». А дальше уже просто проблема преобразования id в названия. Можно разбирать, например, аналогично рубрикам.
В результате вывода десяти записей потребуется всего один запрос к «главной базе».
А уже для выборок «все посты этого ключевого слова» используем таблицу связей.
То есть, грубо говоря, ключевые слова «кэшируются» в основную базу постов.
Так в чем
проблемы-то? =) Я же сразу написал, для чего этот способ нужен. Не надо на него все валить.
У меня, кстати, кэш сделан так: если кэш страницы есть (файл найден), то он выдается. Если его нет, то страница генерится, выдается и пишется в кэш.
Соотвественно, при изменении страницы стираем просто ее файл кэша, никакое поле Last-Modified никуда не пишется.
На грамотно спроектированные mysql-таблицы и оптимизированные запросы валить.
