casey

Бывают случае когда ORM не справиться с запросом. Просто никак.
И бывают запросы когда и нативный ввод SQL тоже не справиться с запросом.
Проблемы бывают как технические, так и архитектурные или скоростные.

Но в любом случае — чем хитрее и оригинальнее обвязка над конечной БД — тем лучше.
Начиная от работы с базой в несколько конектов, заканчивая работой с несколькими базами, или таблицами партироваными на несколько серверов. Или даже прямым отображением на сфинкс.

Так что нарисуйте что вам нужно сейчас, дорисуйте туда столько же из головы, из того что теоритически может вдруг понадобиться потом.
Соберите в единую систему.
И под эту систему ищите инструмент.
Но совсем чистый SQL не используйте никогда — как минимум запросы через свою обертку. Как минимум возмонжость как либо легко менять(или находить в запросе) имена таблиц.

Тоже задавался подобным вопросом. Пробовал доктрину и пропел, но откинул их ввиду большой прожорливости и костылей при сложных запросах. Также раздражало огромное количество вспомогательных файлов (базовые классы, мапперы и т.п.) на каждую модель, сгенерированные этими библиотеками. В итоге сделал свою ORM на базе Zend_Db_Table, Zend_Select (это особенно выгодно, когда сам проект построен на ZF).
Для простых случаев удобно использовать Active Record. Самым удачным примером реализации считаю AR в фреймворке Yii.

ОРМ хорош когда много простых запросов и сущности предметной области хорошо ложатся на структуру бд — ускоряет создание классов-моделей. Сложные запросы с помощью методов, которые предоставляет ОРМ, писать обычно долго и скорее всего выйдет не очень понятный и красивый код. Тут уж имхо лучше нативный SQL.

Android… Ну вы понели.

Если вот этот человек: www.kraynov.com/personal-finance/ соберется и сделает книгу из своего блога, это будет то что вам надо…

Элегантный и быстроработающий, но не самый простой — сделать ветку redis на github, реализовать SRANDMEMBERS, который будет в качестве параметра получать количество возвращаемых результатов, после чего использовать и предложить включить в основную ветку.
Сейчас функция dictGetRandomKey используется в следующих случаях: при экспайре, при получении случайного ключа из базы, при проверке можно ли свопить элемент и при получении случайного элемента множества.
Или же в лоб. SPOP при большой нагрузке — нужно настраивать чтобы redis не начал постоянно пересохранять данные на винт из-за постоянно изменяющихся данных, и ИМХО дополнительный риск их потери.

Можно не платить деньги за параллели, ибо бесплатный виртуалбокс вполне справится с запуском IE, и не только. Я сам на VBox сначала под линуксом сидел, потом перешел на мак. У бокса все передовые функции виртуалок ( ведь оракл продолжает вкладывать большие деньги в его разработку), тут и аппаратное ускорение, поддержка передовой графики, многоядерности. Обновления выходят несколько раз в год. Вобщем, советую!