Комментарии на Восстанавливая память про sql

От Блоголётчик

Блоголётчик — Wed, 23 Sep 2009 13:09:02 +0400

Планируется одна таблица со всеми урлами на сайте, где будут все урлы - и посты, и рубрики, и все остальное. Сейчас вблоголёте это TUrlmap. Одним из требований разработке с бд является отсутствие избыточных данных, то есть урл идеологически правильно хранить в одном месте, да и не только: вот открывается страничка, для ее адреса надо сопоставить (создать) объект, который ссгенерирует контент, ну и следовательно все урлы в одном месте урл, имя класса, и аргумент для функции генерации страницы. В частности, когда открывается страничка поста, то создается экземпляр TPost, где в аргумент = id поста. Все нормально. Теперь же создается новый пост - у него нет еще ни своего id, ни урла. Тоже самое касается и рубрик, меток. Например сейчас в блоголёте, не ограниченным бд, данные дублируются (и я это считаю правильным, на случай их повреждения можно будет как то восстановиться. С бд получается сложнее. Даже если разрешить дублирование, то например генерация нового урла все равно будет еще один запрос к бд, и второй запрос добавление (связывание = заполнение полей) данных о посте (имя класса + id поста для обработки запроса к странице). Дублирование в бд плохо тем, что однозначно найдутся пользователи, которые будут стенать: я написал скрипт, он меняет данные в бд, а сайт не работает, что мне делать, посмотрите мой скрипт? А без общей таблицы урлов, я себе плохо представляю движок, точнее представляю (тот же wordpress), и чтобы сопаставить генератор контента урлу мне совсем не хочется занимться колдоством. Все урлы в одном месте, на мой взгляд, это единственно нормальная ситуация для движка.

От Altesack

Altesack — Wed, 23 Sep 2009 11:31:30 +0400

А урл и пост однозначно соответствуют друг другу?
Если так - то стоит сделать их полями одной таблицы.
Тогда будет один инсерт :)

PS: Я изначально не понял, зачем их пришлось вообще разделять.
Ну да ладно, это другой вопрос.

От Блоголётчик

Блоголётчик — Wed, 23 Sep 2009 10:28:58 +0400

Да, иная модель сохранения данных - данные сохраняются одним махом, наподобии как это сделано в VCL delphi, именно оттуда взята парадигма хранения данных, наложенная на php. И можно сделать сохранение данных (то бишь сериалзованный массив) в бд,и для части классов так и будет, но тогда полностью изчезают преимущства бд.

А sql что то действительно позабыл, например создается пост, делается insert в бд, одно из полей - это id урла, которое в другой таблице, записи в таблице урлов еще нет, второй запрос - создается запись в урлах, третий запрос - обновить в посте id урла. Какое то извращение, у меня умственный шок от этого. Собственно аможно ли это сделать одним запросом? Создать две записи в разых таблицах с перекрестными id друг на друга в готовых записях. Ни черта не помню, да и в принцепе возможно ли это. На днях долго читал про join, пытаясь вникнуть в суть - что то понял, но понял еще и другое - я не мыслю join запросами, и для меня будет всегда прще вложенный запрос. Все мучения из за желания делать оптимизированный компактный код.

От Altesack

Altesack — Wed, 23 Sep 2009 09:41:35 +0400

У тебя просто обалденный движок и обалденная подборка классов, особенно класс для работы с данными! Но вся парадигма сильно отличается от общепринятой, и это главный недостаток.

Приходится мыслить не так, как принято. И со временем это становится проблемой.

Собственно с чем ты и столкнулся.

От Den

Den — Sat, 19 Sep 2009 16:56:47 +0400

Спасибо за полезный материал! Рад был прочесть.