Я уже забыл когда использовал бд, ну то есть от планирования до реализации таблиц, их полей типов, и чтобы это было сразу оптимизированным. Я привык в блоголёте к определенной степени свободы в структуре данных - могу себе позволить абсолютно любые структуры с любыми типами и иерархией. Решил я еще сделать блоголёт и на бд. Начал потихоньку писать sql создания таблиц - ну то есть прописывать название полей таблиц с их типами. Вдруг меня завела во временный тупик простая задача: у постов есть рубрики и категории, а у рубрик и тегов есть посты. Все это я храню в блоголёте в виде массивов id друг друга. В sql нет массивов: только простые типы данных (числа, буквы, строки, время, двоичные, перечислимые и наборы). Массивы подразумевают выборку. Да уж - для перекрестных ссылок друг на друга надо делать новую таблицу, где и будут все эти пары. Получается таблица из двух полей: поста и метки/рубрики.

Отвык я от такого расточительного использования ресурсов, а другой модели данных мне просто в голову не приходит: реально чувствую себя обделенным средствами разработки. Чтобы получить например линки всех меток поста придется делать несколько sql запросов:
- собственно выборка поста
- выборка списка рубрик
- выборка рубрик из предыдущего списка
- выборка урлов из таблицы урлов

все кроме первого два раза. Конечно выборку рубрик можно будет организовать в сложный запрос что то типа
select title from categories, url from urlmap where id in (select childs as id from reftable where parent = postid)

Безусловно, запрос неправильный, надо будет подумать над его реализацией, так как выборка будет из трех таблиц, где для таблицы рубрик выборка по id, из урлов по двум полям (класс и аргумент), а все это берется из запроса к таблице перекрестных. Дурдом однозначно. Всего этого геммороя нет в блоголёте на файлах, а с такими сложными запросами думать про высокую производительность движка вряд ли стоит. Мдя, бля.