Восстанавливая память про sql
18.09.2009Я уже забыл когда использовал бд, ну то есть от планирования до реализации таблиц, их полей типов, и чтобы это было сразу оптимизированным. Я привык в блоголёте к определенной степени свободы в структуре данных - могу себе позволить абсолютно любые структуры с любыми типами и иерархией. Решил я еще сделать блоголёт и на бд. Начал потихоньку писать sql создания таблиц - ну то есть прописывать название полей таблиц с их типами. Вдруг меня завела во временный тупик простая задача: у постов есть рубрики и категории, а у рубрик и тегов есть посты. Все это я храню в блоголёте в виде массивов id друг друга. В sql нет массивов: только простые типы данных (числа, буквы, строки, время, двоичные, перечислимые и наборы). Массивы подразумевают выборку. Да уж - для перекрестных ссылок друг на друга надо делать новую таблицу, где и будут все эти пары. Получается таблица из двух полей: поста и метки/рубрики.
Отвык я от такого расточительного использования ресурсов, а другой модели данных мне просто в голову не приходит: реально чувствую себя обделенным средствами разработки. Чтобы получить например
линки всех меток поста придется делать несколько sql запросов:
- собственно выборка поста
- выборка списка рубрик
- выборка рубрик из предыдущего списка
- выборка урлов из таблицы урлов
все кроме первого два раза. Конечно выборку рубрик можно будет организовать в сложный запрос что то типа
select title from categories, url from urlmap where id in (select childs as id from reftable where parent = postid)
Безусловно, запрос неправильный, надо будет подумать над его реализацией, так как выборка будет из трех таблиц, где для таблицы рубрик выборка по id, из урлов по двум полям (класс и аргумент), а все это берется из запроса к таблице перекрестных. Дурдом однозначно. Всего этого геммороя нет в блоголёте на файлах, а с такими сложными запросами думать про высокую производительность движка вряд ли стоит. Мдя, бля.
← Ранее егог - или как я начинал программировать
Позже Help needed: php вирус →
Комментарии (5) на запись “Восстанавливая память про sql”
Оставить комментарий
У тебя просто обалденный движок и обалденная подборка классов, особенно класс для работы с данными! Но вся парадигма сильно отличается от общепринятой, и это главный недостаток.
Приходится мыслить не так, как принято. И со временем это становится проблемой.
Собственно с чем ты и столкнулся.
Да, иная модель сохранения данных - данные сохраняются одним махом, наподобии как это сделано в VCL delphi, именно оттуда взята парадигма хранения данных, наложенная на php. И можно сделать сохранение данных (то бишь сериалзованный массив) в бд,и для части классов так и будет, но тогда полностью изчезают преимущства бд.
А sql что то действительно позабыл, например создается пост, делается insert в бд, одно из полей - это id урла, которое в другой таблице, записи в таблице урлов еще нет, второй запрос - создается запись в урлах, третий запрос - обновить в посте id урла. Какое то извращение, у меня умственный шок от этого. Собственно аможно ли это сделать одним запросом? Создать две записи в разых таблицах с перекрестными id друг на друга в готовых записях. Ни черта не помню, да и в принцепе возможно ли это. На днях долго читал про join, пытаясь вникнуть в суть - что то понял, но понял еще и другое - я не мыслю join запросами, и для меня будет всегда прще вложенный запрос. Все мучения из за желания делать оптимизированный компактный код.
А урл и пост однозначно соответствуют друг другу?
Если так - то стоит сделать их полями одной таблицы.
Тогда будет один инсерт :)
PS: Я изначально не понял, зачем их пришлось вообще разделять.
Ну да ладно, это другой вопрос.