¿Firebird soporta consultas que devuelven más de un cursor ("record set")?

[[poliburro]]

Empezado por roman

Normalmente, lo que hacemos es un join para mostrar los datos más relevantes en una rejilla, y entonces hacer la o las consultas extras sólo para los registros que realmente nos interese. Es decir, no significa que vamos a hacer las consultas extra por cada uno de los registros de la consulta principal.

Entonces, a lo que me refiero, es que no veo, al menos en este caso específico, una clara ventaja.// Saludos

Exacto¡¡¡¡¡¡¡¡... precisamente la técnica solo es útil para cuando debes hacer múltiples consultas a la base de datos para traterte varios recordsets.

Empezado por roman

Por otra parte, un poco al margen; mencionas que además de SQL Server, hay oros motores que soportan la característica. En el caso particular de MySQL, yo ni siquiera lo mencionaría. Las pruebas que he hecho con procedimientos almacenados (ver. 5.1.x) dejan mucho que desear, dando resultados extremadamente lentos.

caray Román, pues ahí si que puedo decirte, siempre he creido que esa parte está ligada al conocimiento que tenga el diseñador de la administración de bases de datos, del diseño de la base de datos y de la puesta a punto del motor.

Yo tengo un sistema con php y mysql con tablas de más de dos millones de registros y tamaños del órden de gigas de información. y me responde extremadamente rápido con procedimientos almaceandos con una carga de más de 50 usuarios simultáneos escribiendo y consultando.