Как-то докопался до кодов PMA и выяснил что формирование условия у них состоит из чудовищного количества чудовищного кода. Это была еще нормальная, деревянная версия, но работающая на другом уровне.

Все эти методы перекатывания ddl в скрипты - колхоз. Скрипт оказывается спаян с дб намертво, это единое целое в той самой рамке, которая для вас типа уютного бложика для хомячка, без рамки вы потеряетесь как слепой без собачки-поводыря.

Рамки - для тех кто свободно жить не может.

Касательно умозаключения о расходовании ресурсов. Любая рамка заведомо и подчас на 99 процентов избыточна и пожирает ресурсы как кадавр. Не видел я что ли сырцов этих рамок.

Насчет активных записей. Вы же видели как в десктопном программировании берется control и связывается с полем в таблице в бд. Коллекция таких контролей инкапсулируется в объект с типовым набором методов как то вперед, назад, убдейт, дилейт, адд нью. Адд нью ничто иное как кнопка типа reset.

Ума не приложу почему на вебе народ тупо забыл о таких методах, которым в обед стопицот лет.

Можно этот activerecords попросить создать control и вернуть ему этот control чтобы activerecords записал данные в ячейку таблицы бд о которой он узнал из "вернутого" элемента управления?

Yii wrote: CRUD (create, read, update, delete) features...

Одуреть. Это же DML - data manipulation language.

Про ресурсы.

5. Application Life Cycle
...

Не многовато?

И в контроллере еще раз:

if($contact->id > 0) // update
		{
			$contact->isNewRecord=false;
			if(($oldContact=Contact::model()->findByPk($contact->id))!==null)

Короче все через ж.

Мы же знаем что id это pk. Следовательно в модели, там где перечисляются поля на выход, должно быть $this->pk = 'id', а затем в контроллере, соответственно if($contact->pk > 0) и далее _не_ по тексту, потому что findByPk обламывается - она уже не нужна.

И вы пишите куча лишних запросов будет, и бла-бла-бла. Так вот и в модели ничего не надо прописывать вручную, потому что найти какое поле - pk - очень просто. Смотрим флаги. Если авто-инкремент - значит берем это имя, иначе смотрим дальше, если primary key - берем его, иначе смотрим дальше, если unique key - берем его и смотрим дальше.

Дальше можно по настройкам. Если в настройках написано типа use_any_key_as_pk = 1 надо попытаться составить ключ из нескольких полей. Сначала берутся типа число, типа дата, потом типа текст и все такое.

В практическом же смысле в этом поиске чего-нибудь типа ключа - смысл вредный. Таблицы нормальной БД всегда оборудованы каким-нибудь явным pk. А не нормальные БД посылаются к черту, вместе с их создателями. Таким образом заодно отсекается контингент полных идиотов с которыми все равно на форуме тех-поддержки намаешься.

Подытожим. Может класс ДБ найти ключевое поле данной таблицы? Может, элементарно. Может класс ДБ найти правило для данной таблицы в таблице правил, имя которой свободно прописывается в конфиге, который сам таблица, имя которой - единственное что _знает_ ПО вдобавок к имени БД. Может. Может класс ДБ поднять отношения данной таблицы и загрузить все остальные таблицы через запрос? Стало быть если скажем сама таблица модели имеет отношения, "моделька" сама себя поднимет за усы из болота, достанет все правила, сделает запрос, нормализует данные, выложит их в проперь - берите кто хотите и рендерите что угодно.

function __get($table) {
    return $this->from($table);
}

$apdo->fruits->key(123)->delete();