еще рекомендую в таких случаях сделать так:
$client = Client::model()->with('orders')->findByPk($id);
и еще немного сахарку - вместо ['client'=>$client] можно написать compact('client'). В случае если нужно будет добавить элемент в массив довольно удобно. Но это так.
Индексы добавляли? Не обязательно даже составные индексы, в теории mysql если не сильно старая сама мердж индексов сделает. И после каждого изменения смотрите эксплейн.
в 5 раз дольше при каких изменениях? При внесении условия published=1 в on? при замене left join на inner join (у вас же картинки принадлежат играм, или картинка может быть сама по себе?) И все же зачем вам count и group by в запросе? там же связь один ко многим (игра к картинке)...
мне удобнее написать что-то типа такого: SELECT u FROM MyUserBundle:User u WHERE u.id = :id ORDER BY u.name ASC нежели юзать query builder. Всеравно я все выборки в репозитории реализую. Так что со стороны контроллера и вообще всего приложения это будет выглядеть как $userRepository->getUser($id).
атрибут id не для этого придумали. Вдруг у вас будет несколько ссылок на один и тот же фильм?. Для этих целей и была введена спека по data-* атрибутам и ненадо ничего выдумывать. Сменить можно так же - либо через attr (поменяется значение атрибута) или что лучше - через метод data
да, можно, но если этого будет слишком много код превратится в кашу. Исключения нужны для критических мест приложения от которых зависит ее работа, их принято кидать из библиотек... короче из сервисного слоя. Повышает реюз кода.
ну как... вообще виртуальная машина js-а (во всяком случае v8) оптимизирует только локальный код. То есть если у вас идет доступ к глобальной переменной, никаких оптимизаций существенных (сокращающих время доступа к пропертям, элементам массива и т.д.) не будет.
$client = Client::model()->with('orders')->findByPk($id);
и еще немного сахарку - вместо ['client'=>$client] можно написать compact('client'). В случае если нужно будет добавить элемент в массив довольно удобно. Но это так.