Cita:
Iniciado por hhs 
Propel cuenta con un Query Builder muy potente, que opciones recomiendas NSD ?
No he usado Propel en un proyecto real por lo que no estoy calificado como para decir realmente cuales son sus limitaciones, al ser parte de un ORM, también es difícil de saber (sin ponerse a usarlo y a probar, me refiero) si los que a simple vista lo parecen, son realmente limitantes.
La impresión que me lleve al leer la documentación (que por cierto, la leí semi-completa hace un tiempo, no solo este caso particular) es que tiene muchas cosas para hacer poco, y que las tareas mundanas de todos los días se vuelven complejas (por ejemplo este caso de hacer un par de joins) a cambio de simplificar otras tareas que rara vez son requeridas.
Un query builder que me gusto desde el punto de vista de la usabilidad es el de
Laravel, sumamente elegante y que no complica las cosas mas de lo estrictamente necesario.
Otro que es un poco mas complejo pero interesante es el de
Zend, si bien es mas complejo que el de Laravel, también es mas extensible que este.
Doctrine por su parte también tiene uno interesante aunque no tan completo como los anteriores.
Al lado de estos, Propel, (desde mi punto de vista) es mas limitado.
No obstante, todos los mencionados previamente, tienen 3 grandes problemas:
1) Dependencia del entorno:
Cada uno esta pensado para integrarse perfectamente con su Framework o con componentes de este, pero al sacarlo de allí y querer usarlo de forma aislada presentan inconvenientes o molestias que obligan a adaptarse a su forma de trabajar.
2) Eficiencia y organización:
En general, cada QB son decenas de archivos, decenas de clases, cientos de métodos, muchas interfaces, muchas lineas de código, etc que terminan por lograr, que solo el que las programo las entienda y que un simple SELECT demore mucho mas de lo que debería simplemente por el nivel de abstracción del modelo.
3) Ineficiencia en sentencias preparadas:
Ninguno de estos query-builder saca provecho de las sentencias preparadas. Las usan como medio de seguridad pero no de optimizacion.
Así, si yo quiero realizar 20 consultas, termino preparando 20 sentencias en vez de reutilizar las anteriores.
Ni hablar de los que ademas, se basan en PDO.
Personalmente prefiero usar DBAL simples, de un solo archivo, una única clase, menos de 1500 lineas de código incluyendo documentación. Por
ejemplo esta que es la que actualmente me encuentro desarrollando, donde intento implementar de forma minimalista, los métodos y características mas útiles de los QB antes mencionados y de muchos otros mas pequeños que son muy precarios pero que tienen una idea interesante dentro.