Восстанавливая память про sql
Рубрики: php, Блоголёт, Новости ; Метки: mysql, 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, из урлов по двум полям (класс и аргумент), а все это берется из запроса к таблице перекрестных. Дурдом однозначно. Всего этого геммороя нет в блоголёте на файлах, а с такими сложными запросами думать про высокую производительность движка вряд ли стоит. Мдя, бля.
Подписаться на RSS комментариев к этой записи
Ранее егог - или как я начинал программировать | Позже Help needed: php вирус
19.09.2009 в 16:56
Спасибо за полезный материал! Рад был прочесть.
23.09.2009 в 09:41
У тебя просто обалденный движок и обалденная подборка классов, особенно класс для работы с данными! Но вся парадигма сильно отличается от общепринятой, и это главный недостаток.
Приходится мыслить не так, как принято. И со временем это становится проблемой.
Собственно с чем ты и столкнулся.
23.09.2009 в 10:28
Да, иная модель сохранения данных - данные сохраняются одним махом, наподобии как это сделано в VCL delphi, именно оттуда взята парадигма хранения данных, наложенная на php. И можно сделать сохранение данных (то бишь сериалзованный массив) в бд,и для части классов так и будет, но тогда полностью изчезают преимущства бд.
А sql что то действительно позабыл, например создается пост, делается insert в бд, одно из полей - это id урла, которое в другой таблице, записи в таблице урлов еще нет, второй запрос - создается запись в урлах, третий запрос - обновить в посте id урла. Какое то извращение, у меня умственный шок от этого. Собственно аможно ли это сделать одним запросом? Создать две записи в разых таблицах с перекрестными id друг на друга в готовых записях. Ни черта не помню, да и в принцепе возможно ли это. На днях долго читал про join, пытаясь вникнуть в суть - что то понял, но понял еще и другое - я не мыслю join запросами, и для меня будет всегда прще вложенный запрос. Все мучения из за желания делать оптимизированный компактный код.
23.09.2009 в 11:31
А урл и пост однозначно соответствуют друг другу?
Если так - то стоит сделать их полями одной таблицы.
Тогда будет один инсерт :)
PS: Я изначально не понял, зачем их пришлось вообще разделять.
Ну да ладно, это другой вопрос.
23.09.2009 в 13:09
Планируется одна таблица со всеми урлами на сайте, где будут все урлы - и посты, и рубрики, и все остальное. Сейчас вблоголёте это TUrlmap. Одним из требований разработке с бд является отсутствие избыточных данных, то есть урл идеологически правильно хранить в одном месте, да и не только: вот открывается страничка, для ее адреса надо сопоставить (создать) объект, который ссгенерирует контент, ну и следовательно все урлы в одном месте урл, имя класса, и аргумент для функции генерации страницы. В частности, когда открывается страничка поста, то создается экземпляр TPost, где в аргумент = id поста. Все нормально. Теперь же создается новый пост - у него нет еще ни своего id, ни урла. Тоже самое касается и рубрик, меток. Например сейчас в блоголёте, не ограниченным бд, данные дублируются (и я это считаю правильным, на случай их повреждения можно будет как то восстановиться. С бд получается сложнее. Даже если разрешить дублирование, то например генерация нового урла все равно будет еще один запрос к бд, и второй запрос добавление (связывание = заполнение полей) данных о посте (имя класса + id поста для обработки запроса к странице). Дублирование в бд плохо тем, что однозначно найдутся пользователи, которые будут стенать: я написал скрипт, он меняет данные в бд, а сайт не работает, что мне делать, посмотрите мой скрипт? А без общей таблицы урлов, я себе плохо представляю движок, точнее представляю (тот же wordpress), и чтобы сопаставить генератор контента урлу мне совсем не хочется занимться колдоством. Все урлы в одном месте, на мой взгляд, это единственно нормальная ситуация для движка.