Blog title

О фильме “Адмирал”: …Конец немного предсказуем. Где-то с середины фильма было такое чувство, что в конце Колчака растреляют. Так и вышло… Отсюда . Похоже мем займет достойное место в коллекции Луркоморья .

Некоторое время назад наткнулся на хороший и полезный русскоязычный блог посвященный CakеPHP. Можете добавить к себе в закладки и/или RSS-ридер: Программируем на CakePHP . Мне понравилось. Посты достаточно разноплановые, но все в той или иной степени полезные. Самое важное – автор не забросил свое начинание после 2-3 постов, так что есть надежда, что проект будет жить и дальше. Еще интересный проект, правда неоконченный. Марафон MVC фреймворков . Автор пытается создать проект на разных фреймворках и оценивает различные особенности каждого. Участвуют ASP.NET MVC, CakePHP 1.2RC2, Catalyst 5.7, Django 0.96 и RoR 2.1. Мысль давно сидящая в голове : а не пора-ли мне с Blogger’а съехать на standalone? :-)

Окончание о болезнях роста баз данных . Как и предсказывали друзья , переход на InnoDB и шаманство с типами связующих полей двух больших таблиц в MySQL не дали сколько-нибудь приемлемого результата. После размышлений о непредсказуемом результате, смысле жизни, затратах на смену СУБД, от перевода всего на PostgreSQL решил отказаться. Против лома нет приема и построчный перебор результатов запроса решил сделать обычными методами PHP, в обход Cake. Тоже, скажем прямо, не Cake way :-) Первым делом поискал гугловской группе сообщения на аналогичную тему. Таки да, есть люди со схожими запросами . Более того, во глубине сибирских руд классов CakePHP есть метод fetchRow, но он неинтересен совершенно. При выполнении запроса Cake хранит ссылку на результат последнего запроса у себя в свойстве и перебирать построчно результаты можно, только если при этом не выполнять никаких других запросов. В противном случае результат запроса, естественно, будет перезаписан. Поэтому задача перебора строк...

Две таблицы в БД. Обе примерно по полмиллиона записей, а в рабочем виде будет и больше, миллиона 2-3. Таблицы не сами по себе, а связанные Один-ко-многим. При LEFT JOIN все это безбожно тормозит, невзирая на тип ключей, по которым идет связка, пробовал и INT вместо VARCHAR, который там изначально. Думаю над тремя вариантами. Обработку связей унести в код модели/контроллера Cake. т.е. SELECTить все по одельности. Попробовать InnoDB вместо MyISAM Перенести на PostgreSQL Пока обдумываю варианты, как буриданов осел, работа не движется. Буду пробовать на выходных сначала пункт 2, как наиболее простой в реализации, потом 3, потом 1-й как самый, на мой взгляд, идеологически неверный :-)