Ну на моей памяти частенько приходилось использовать подключения к двум базам. MySQL для хранения, скажем, транзакций, платежей, счетов пользователей и MongoDB для организации чего-то требующего большей гибкости, скажем атрибуты и геоиндексы.
функцию live вообще никогда не рекомендовали к использованию, она просто была и все. Это делегат на уровне document. Мол когда событие на странице происходит, оно пробрасывается вверх по дереву, пока кто-то его не не остановит или же пока оно не дойдет до document. А уже в обработчике проверяется кто именно вызвал событие, и выполняется действие.
Это проблема ни симфони, и ни доктрины, если вы понимаете о чем я. С другой стороны вам нужно просто связанный тип данных. Если у вас связи проставлены верно, то они должны подхватиться и забить все сами. Скорее всего вам опять стоит проверить связи. И желательно предоставить информацию о внешних ключах у этих двух таблиц. По ним можно точно судить что да где не так пошло.
AR примитивна, и не позволяет решать массу задач. Пока то что я видел, это если встречается задача чуть сложнее стандартной — уже начинаются кастыли, переопределение методов базовых классов, танцы с бубнами и т.д. DI вообще отсутствует, напрочь. Очень неудобно всю логику разносить только по моделям и бихейверам. Я помню восторг с которым начинал работать с этим фреймворком (учитывая отсутствие достойных и простых альтернатив), но сейчас, я не вижу никаких преимуществ у Yii перед другими (разве что для небольших проектов он все еще проще, но небольшие проекты я лучше на Node.js напишу или на Silex). По сути единственная достойная штука в Yii это Zii, причем почти все виджеты для себя я переписал под свои задачи. Вот к примеру несколько вещей, которые мне пришлось решить через кастыли: накатывание миграций в транзакции — непонятно почему, иногда при ошибке в миграции (на уровне компонентов приложения) исключения не отлавливались в базовом классе, и это приводило к тому что транзакция по каким-то причинам ломалась. Пришлось переписать немного миграции что бы все было хорошо. Раутинг — он вообще нулевой. В нем нету поддержки ивентов, так что докручивать какую-то логику приходится путем переопределения методов. CDbCriteria — это вообще кашмар, особенно если нужно составить сложный запрос с джойнами (есть пара классов задач, при которых это единственная альтернатива подзапросам) приходилось долго материться, ибо разработчики решили за всех что «будет лучше если условия будут записываться в директиву ON, ибо никто не думает о производительности». Тобиш просто есть два параметра, которые делают одно и то же.
Просто когда вижу код какого-либо проекта на Yii, я всегда могу найти место где разработчики вставили какой-то кастыль, или просто неопрятный код, который нужен лишь для того, что бы все работало.
По поводу уровня комьюнити — это никак не связано с расширениями. Хотя с другой стороны расширений для Yii написанных явно на высоком уровне еденицы. Все остальное — можно и самому за вечер наваять. В плане количества/качества расширений Yii уж точно уступает монстрам аля Zend/Symfony. Но опять же это не главное. Об уровне можно судить банально почитывая официальный форум. Да, есть достойные люди, но их мало.
Я пишу на Yii вот уже 3-ий год, и с каждым днем задачи становятся все более неподьемными для этого фреймворка. А Yii2 — а там ничего не будет что бы координально поменять ситуацию. Покрайнемере из того что было оглашено, все плюшки можно реализовать самому за пару вечеров.
Словом, я не спорю, для начала Yii может и не плох, но Yii может плохому научить. Я думаю что понять логику MVC приложений можно лучше, реализовав такое при помощи микрофреймворка, который за разработчика делает минимум. Да и вообще, можно взять несколько фреймворков, менять их, смотреть другие. Поняв принципы, переход с одного фреймворка на другой будет довольно простым.
У Yii очень много проблем с ORM (и не только), он не поворотлив, не гибок. Если нужно сделать проект больше среднего, то приходится сильно напрягать мозги что бы сделать что-то правильно. Накипело.
Но зато у него низкий порог вхождения (это же и минус, слишком слабое по уровню комьюнити в среднем) и он прост как пробка.
собираться все будет в любом случае при помощи composer, просто прописать команду. А так, тот же less эффективнее и надежнее использовать именно с родной библиотечкой, что так или иначе понадобится при сборке того же twitter bootstrap. Хотя тут можно легко обойти все это дело.
в любом случае, если хотите решение через компоузер — вам его предложили выше.
Фишка FPM как раз в том что бы гибко (от хоста к хосту) менять конфиги, права и т.д. И это относится именно к FPM, ибо можно спокойно nginx заменить на какой-нибудь lighthttpd (хотя смысла нету)
