[guillotmarc]

Hola.

Empezado por marto

Pues si no me equivoco, gracias al dialecto de MySql, puedes crear heap con los datos que necesitas en tu subconsulta y usarla en la query principal. No suple a todas las subconsultas pero sí a alguna.
Lo que quiereo decir con esto es que, si bien es cierto que le faltan algunas características comunes a otros servidores, la peculiaridad de MySql hace que te perimita hacer las mismas cosas "de otras maneras".

Pero eso indica que el lenguaje de consultas es limitado, te fuerza a definirte objetos adicionales en la base de datos, para obtener esos resultados (ya sean vistas, tablas temporales o heap tables, que en el fondo hace lo mismo pero de forma más eficiente al residir totalmente en memoria).

¿ Que ocurre si no eres el Administrador de la Base de Datos ?. Si solo tienes derechos a realizar consultas, pero sin poder crear objetos, vas a tener que complicarte la vida haciendo calculos en el cliente.

Empezado por marto

No quería decir que no necesitase subconsultas sino subconsultas sincronizadas

Gracias, no conocía la traducción al castellano de los correlated subquerys. Te recomiendo que los utilizes, són muy utiles, te permiten sacar resultados complejos en la misma consulta.

Empezado por marto

Pues no sé cómo se haría en MySql (que no dudo que se puede, pero lo tengo algo olvidado), pero, de todas maneras, ese tipo de consultas las acostumbro a hacer con procedimientos, mucho más eficientes, por lo menos en Oracle que es con lo que trabajo habitualmente.

Pues en MySQL tampoco tienes esta opción, ya que las versiones estables no soportan procedimientos almacenados. Y está por ver si la versión 5 va a permitir utilizar un procedimiento almacenado como una función en una consulta, ya que tengo mis dudas de que esto forme parte del estándar SQL (SQL Server 7, por ejplo., no admitía esta posiblidad).

Naturalmente muchas veces habrá alguna forma de sortear el problema. Por ejemplo se me ocurre crear dos vistas como :

create view NumVentas as 
select Codigo, count(*) as nVentas
from Ventas inner join Clientes on Clientes.Codigo = Ventas.Codigo
group by Codigo
 
create view NumPedidos as 
select Codigo, count(*) as nPedidos
from Pedidos inner join Clientes on Clientes.Codigo = Pedidos.Codigo
group by Codigo

Entonces ya puedes realizar la consulta :

select Codigo, nVentas, nPedidos
from Clientes
	 left outer join NumVentas on Clientes.Codigo = NumVentas.Codigo
	 left outer join NumPedidos on Clientes.Codigo = NumPedidos.Codigo

El resultado es el mismo (aunque no siempre habrá esta posiblidad), pero no es comparable la elegancia y sencillez de la solución con subconsultas, que el tener que utilizar vistas o procedimientos almacenados. Además de el hecho ya comentado de que la persona que necesita la consulta, quizá no tenga la posiblidad de crear objetos en la base de datos.

Empezado por marto

ese tipo de consultas las acostumbro a hacer con procedimientos, mucho más eficientes, por lo menos en Oracle que es con lo que trabajo habitualmente.

No estoy de acuerdo en absoluto. Si tienes los indices adecuados, se van a utilizar los mismos índices en la correlated subquery y en el procedimiento almacenado, resultando en el mismo rendimiento. O quizá ligeramente mejor en la subconsulta, puesto que no tiene la sobrecarga del paso de parámetros y recogida del resultado. (aunque esto último es solo una estimación mía).

Saludos.