to Zolter
Вы меня извините конечно, но ИМХО “перерос”, это когда наоборот, мыслей угробить архитектуру приложения в угоду скорости уже не возникает. 
P.S. Перевод AR в DAO путем перегрузки методов первого - это преступление против Yii и по хорошему должно караться принудительными работами в native php4 на неделю. 
Ладно… потрачу свое время, но отпишу ответ нормальный на ваше сообщение.
Может. Идеи разные бывают. Вот например ваша идея - не оптимизируйте свои приложения, тупо докупайте новые сервера, но зато получите мега маштабируемость.
в случае перезагрузки методов AR о чем собственно шел разговор - DAO не сколько "РАЗРАБОТКУ" не замедлит.
способствует написания это как? в случае перезагрузки методов AR для улучшения запрсов которые оно формирует по средствам DAO - разработчик как использовал методы AR так и будет. Совершенно не напрягаясь AR будет формировать запросы в конечном итоге или нет
еще одно пустое высказывание. причем тут облегчает жизнь при командной разработке? Команда как использовала методы AR так и будет! Вы с темы не переключайтесь. Мы обсуждаем не приемущества чистого AR над чистым DAO, а момент перезагрузки методов AR.
Скорость разработки в нашем случае отличается только на написание самой перезагрузки методов. Что при командной разработке, да и без команды - не больше часа времени. Получить лишний час, или уменьшить производительность в пару процентов - вот в чем вопрос.
Вы всегда кеширование используете? Это что верх оптимизации : кешировать всё что только можно? Хочу вас разочаровать, в проектах с высокой нагрузкой, где кол-во онлайна от 500 живых душ - данные очень быстро изменяются. И кешировать большую часть фрагментов не представляет возможности. Понимаете? Тут не всегда вам кеширование поможет, а это как понимаю ваш единственный козырь в сторону ускорения работы.
а для приложений без кеширования, или таких как я описал выше - будет полная жопа. Плюс AR жрет намного больше памяти, что фактически при здоровом онлайне - весьма важно. Будет то 15мб на 1 человека, или 3.
Речь идет о перезагрузке методов, а не переходе к чистому DAO. В случае перезагрузки - потеря мне не заметна.
Все приложения используют behaviors? А зачем он вам собственно? Вы им что данные с базы связанные удаляете? А для чего тогда возможности самой базы для этого?
А что с EAV в случае перезагрузки методов AR работа остановится или что? Сложные behaviors это какие? Приведите мне пример behavior-а который тяжело реализуем если методы AR будут перезагружены.
ну вот началось 
то же мне горячие финские парни(с)
2Zolter
Как я понимаю Вы говорите о том что бы перегрузить некоторые методы AR для того что бы на выходе получить массивы ?
Как мне кажется нужно всегда искать компромисс.
Порой нужна толькоодна циферка подсчитанная через SUM или AVG или еще что то … и в принципе это проше да и разумнее как мне кажется написать
с помощью createCommand.
Другое дело что есть огромные плюсы от использывания AR в том числе и скорость разработке, и выборка связанных данных, и объектный подход.
у одного и у другого подхода есть свои достоинства и не достатки.
На мой взгляд важен здоровый компромисс
Я не спорю что DAO и AR разные вещи и написаны для разных моментов. Я же не отрицаю.
Я говорю к тому что если вы пишите высоконагруженую систему - то надо здраво смотреть в сторону оптимизации, и ненужный функционал попросту выкидывать. Есть люди для которых тяжело писать запросы в ручную, им проще освоить AR. Но в реальности то что ты не имеешь знаний - перед заказчиком тебя не освобождает. И если проект (не маленький, оч нагруженный и посещаемый) предполагает то, что возможно избавится от AR с минимумом потерь - тогда это стоит сделать.
Против AR я сам ничего не имею и очень часто использую. Иногда очень помогает и упрощает жизнь.
Есть куча проектов где AR нафиг не надо, и не используется даже на 25% мощности. Но завто ресурсы оно жрет конкретно. Так зачем оно там надо? Перегрузите, заюзайте DAO. А потребуется мега маштабированость, бетвины и тп - так некто потом не мешает удалить перезагруженые методы и все!
Если вы не заметили, то я нигде не писал, про вред оптимизации. Конкретно было написано про вред оптимизации методом перегрузки AR методов и это практически в 99% случаев, если речь идет о больших высоконагруженных проектах, разрабатываемых в комманде. Более того, предложив такую идею в массы, коллеги просто усомнятся в вашей компетентности. Предложите такую идею django’истам или ROR’овцам, закидают помидорами, приговаривая, что php’шники опять в своем духе. AR и память которую он кушает - это не самое узкое место. Да, это медленнее, но это одно их тех немногих мест, оптимизацию в котором лучше провести докупкой железа.
Да? А если нужно будет добавить пару значений в with option. Лезть в перегруженный метод и менять логику? Или вы все жестко прописываете в ТЗ и шаг влево и вправо - расстрел? Тогда зачем вам RAPID/AGILE средство разработки, которым Yii напрямую является?
Вот и я о том же, пара процентов не стоит того говн.кода в модели.
Вы палку то не перегибайте по поводу единственного козыря в сторону ускорения. Если кто то не согласен с вашими идеями, это не значит, что он чем то ограничен и т.д., это просто значит, что на то могут быть очень веские основания. Что касается кеширования. То вы можете просто математически подсчитать, что будет если поставить в кеш массив AR объектов на 30 секунд при такой дикой посещаемости. Вопросы сразу отпадут, т.к. производительность возрастет в разы. Или вы не можете позволить себе кеш в 30 секунд? Что касается невозможности кеширования большинства фрагментов, то возможность представляется. Все зависит от архитектуры приложения и политики кеширования.
Опять ваши предположения, на грани оскорбления. Для удаления используются возможности INNODB engine, это для тех кто использует MySQL. Что касается behaviors, то в более менее серьезном приложении они очень плотно используются, а если уж речь о крупном проекте…
Да не вопрос. Вы наверное не видели behavior’s весом килобайт в 10 с очень сложной логикой. Приведу кусок кода который напрямую работает с метаданными объектов AR динамически формируя связи с другими моделями.
public function updateEntityRelation($parameters)
{
$entityMd = Entity::model()->getMetaData();
$schema = $this->owner->getCommandBuilder()->getSchema();
foreach ($parameters as $parameter)
{
$type = $parameter->attribute->type->title;
$with = array();
if ($type === 'list')
$with = array('data');
$on = '??.attributeID='.$parameter->attribute->id;
$name = $parameter->attribute->name;
$alias = $schema->quoteColumnName($name);
$entityMd->relations[$name] = new CHasOneRelation(
$name, 'Entity'. ucfirst($type), 'entityID',
compact('with', 'on', 'alias')
);
}
$md = $this->owner->getMetaData();
$md->relations['entity']->with = array_keys($entityMd->relations);
}
Вы глубоко ошибаетесь. Людям без идеального знания SQL в AR делать просто нечего. Чтобы использовать все возможности AR максимально эффективно, необходимо запастись соответствующими знаниями про то, что он делает на самом низком уровне. Поэтому предположение про людей, которым проще - это миф. Нет таких людей. А если и есть, то их еденицы и к веб разработке они точно подошли не с того бока.
Что касается высоконагруженного большого проекта, то он по определению своему уже не предполагает возможности избавиться от AR с минимумом для своего дальнейшего развития потерь, ибо технологичен уже на уровне своего проектирования.
to Zolter
P.S. Давайте не будем ругаться и спорить. Потому как, пока мы это делаем, передовики плотно изучают и планируют внедрение MongoDB в своих проектах. Благо там наличие таких споров изначально не возможно.
Согласен по поводу прекращения споров. Изначально я тебе сразу говорил что это не к чему не приведет. Тут каждый останется при своем мнение полюбому. У тебя свой опыт за спиной, у меня свой. Тут не настолько прямые вещи которые в которых можно точно доказать правоту или ошибку одного из нас.
Раз уж речь зашла о кеше, то пооффтоплю, а как идеологически вернее использовать его с AR, имеется в виду чистое кеширование данных отданых моделью: переопределять методы, расширять модель, кешировать в контролере?
to necros
Кешировать в контроллере. Хотя идея с CActiveRecordBehavior выглядит соблазнительно.
извиняюсь что поднимаю тему, но меня интересует такой вопрос, понимаю что используя relations в AR будет правильнее, но поскольку уже был написан интерфейс редактирования списков, а писать занова уже нет времени, да и как понимаю под каждый тип нужно ещё создавать отдельную модель и таблицу, да ещё и отдельный шаблон для их редактирования.
Сейчас у меня реализована одна таблица в ней храняться разные списки, списки отделяются отдельным полем type. Есть также таблица записей которая имеет отдельные поля(за место создания отдельных таблиц для их хранения) к примеру один из типов хранит данные такого вида(к примеру тип Жанры genre) 23,463,2 или 45 или 3,87 и т.п. Допустим чтобы мне получить записи которые содержат ID 87 из приведённого выше примера, то генерирую такой запрос
$criteria->condition = " genre regexp '[[:<:]](87)[[:>:]]' ";
вопрос, на сколько будет медленнее мой вариант чем если делать через relations ?
понимаю что использование регулярные выражения только снижает производительность, но если использовать кэширование в AR, то не сильно критично будет в сравнеии если всё делалось с relations ?