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

[roman]

Empezado por roman

Y volviendo al tema original, ¿qué ventaja representa devolver tres recordsets en lugar de hacer un join normalito que enlace ls tres tablas?

Y, ¿hay respuesta para esto? O nos quedamos con que es parte del estandar

// Saludos

[[poliburro]]

Empezado por roman

Y, ¿hay respuesta para esto? O nos quedamos con que es parte del estandar

// Saludos

Amigo me avoco a tu duda planteada aquí:

Empezado por roman

Y volviendo al tema original, ¿qué ventaja representa devolver tres recordsets en lugar de hacer un join normalito que enlace ls tres tablas?

Y sí. No lo sé. Por eso pregunto.

Siguiendo el ejemplo que he posteado en mi blog, si tienes las tablas de encabezado de venta, detalle de venta e información de clientes. devolver toda esa información como un solo join normalito te genera una tabla con la siguiente estructura:

filasdatoscliente, datosencabezadoventa, partidadeventa1
filasdatoscliente, datosencabezadoventa, partidadeventa2
filasdatoscliente, datosencabezadoventa, partidadeventa3
...........
filasdatoscliente, datosencabezadoventa, partidadeventaN

como puedes observar, hacer uso de joins para devolverver toda esa información agrupada es sumamente infeciente pues vas a devolver un recordset con información duplicada y que te exigirá seprarla en tu código para mostrarla en los diferentes repositorios.

Lo que hace la mayoria de programadores es primero consultar el maestro de ventas, luego el detalle de venta y para terminar los datos del cliente. Es la manera tradicional y por cada llamada debes estar haciedno consultas separadas o llamando a los procedimientos almacenados correspondientes. Eso está muy bien, pero si buscas optimizar las llamadas a la base de datos y aprovechar una sola conexión, pues, podrías optar por devolver los tres bloques separados y de esa manera te ahorras todo el trabajo de estar invocando consultas separadas.

esta es una técnica como tantras otras. Podrías decirme que puedes deolverlo en un gran bloque xml, o podrías decirme que prefieres hacer tres consultas a la base de datos o podrías decirme que devolverás todo en un solo gran resultset. Eso queda ya en ti como programador y tus criterios técnicos.

[Casimiro Noteví]

Empezado por poliburro

Amigo me avoco a tu duda planteada aquí:
Siguiendo el ejemplo que he posteado en mi blog, si tienes las tablas de encabezado de venta, detalle de venta e información de clientes. devolver toda esa información como un solo join normalito te genera una tabla con la siguiente estructura:

filasdatoscliente, datosencabezadoventa, partidadeventa1
filasdatoscliente, datosencabezadoventa, partidadeventa2
filasdatoscliente, datosencabezadoventa, partidadeventa3
...........
filasdatoscliente, datosencabezadoventa, partidadeventaN

como puedes observar, hacer uso de joins para devolverver toda esa información agrupada es sumamente infeciente pues vas a devolver un recordset con información duplicada y que te exigirá seprarla en tu código para mostrarla en los diferentes repositorios.

Si la idea es buena, es curioso, nadie ha dicho que sea malo, es interesante, etc.

Lo único que ha ocurrido en todo esto es que, sin saberlo, añadiste a tu comentario (sin venir a cuento): "algo más por agregar a la larga lista de cosas que no soporta firebird".
Porque de momento nadie ha podido decir si lo implementa o no. Que puede ser que no lo implemente... seguramente es así.
¡¡¡Tantas cosas hay que hacen unos y que no hacen otros!!!

[[poliburro]]

Empezado por Casimiro Notevi

Lo único que ha ocurrido en todo esto es que, sin saberlo, añadiste a tu comentario (sin venir a cuento): "algo más por agregar a la larga lista de cosas que no soporta firebird".
Porque de momento nadie ha podido decir si lo implementa o no.

claro que fué sin saberlo y por eso precisamente lo dije de la siguiente manera:

Empezado por poliburro

No se si lo soporte Firebird, supongo que sería algo más por agregar a la larga lista de "cosas" que no soporta.

Aclaré que no lo sabia y que de no soportarlo sería algo por agregar a la larga lista de "cosas" que no soporta.

Jamás me mostré como un experto en firebird sin saber del tema. No conozco firebird tan a profundidad como para poder declarar que no soporta algo.

[Casimiro Noteví]

Empezado por poliburro

claro que fué sin saberlo y por eso precisamente lo dije de la siguiente manera:
Aclaré que no lo sabia y que de no soportarlo sería algo por agregar a la larga lista de "cosas" que no soporta.

Ya, y también puede ser algo a agregar a interbase, mongodb, informix, netezza, ingress, sqlite, dbase, foxpro...

[[poliburro]]

Empezado por Casimiro Notevi

Ya, y también puede ser algo a agregar a interbase, mongodb, informix, netezza, ingress, sqlite, dbase, foxpro...

pues si.. solo que en este hilo se delimitó desde el inicio claramente a Firebird... o me equivoco?

[Casimiro Noteví]

Empezado por poliburro

pues si.. solo que en este hilo se delimitó desde el inicio claramente a Firebird... o me equivoco?

En eso te doy la razón.

[roman]

Empezado por Casimiro Notevi

Si la idea es buena, es curioso

O sea, ¿es curioso sólo cuando la idea es buena?

¿O te refieres a sí, la idea es buena, es curioso...?

// Saludos

[Casimiro Noteví]

Empezado por roman

O sea, ¿es curioso sólo cuando la idea es buena?

¿O te refieres a sí, la idea es buena, es curioso...?

Me comí la coma

[roman]

Empezado por poliburro

devolver toda esa información como un solo join normalito te genera una tabla con la siguiente estructura:

filasdatoscliente, datosencabezadoventa, partidadeventa1
filasdatoscliente, datosencabezadoventa, partidadeventa2
filasdatoscliente, datosencabezadoventa, partidadeventa3
...........
filasdatoscliente, datosencabezadoventa, partidadeventaN

como puedes observar, hacer uso de joins para devolverver toda esa información agrupada es sumamente infeciente pues vas a devolver un recordset con información duplicada y que te exigirá seprarla en tu código para mostrarla en los diferentes repositorios.

Lo que hace la mayoria de programadores es primero consultar el maestro de ventas, luego el detalle de venta y para terminar los datos del cliente. Es la manera tradicional y por cada llamada debes estar haciedno consultas separadas o llamando a los procedimientos almacenados correspondientes. Eso está muy bien, pero si buscas optimizar las llamadas a la base de datos y aprovechar una sola conexión, pues, podrías optar por devolver los tres bloques separados y de esa manera te ahorras todo el trabajo de estar invocando consultas separadas.

Gracias por la respuesta

No dudo que pueda tener sus ventajas. Y no lo dudo para empezar porque ni siquiera tenía conocimiento de esta característica hasta hace unas horas.

Pero, sin ánimo de demeritar, no me parece que tu ejemplo sea clarificador. Para empezar, lo de los datos repetidos, pues todo depende de no hacer un select .* y escoger los campos adecuados de cada tabla.

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.

-------

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.

// Saludos

[[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.

[roman]

Tendría que revisarlos. Porque ciertamente no soy ducho en eso. Se trataba de uns procedimientos que se limitaban a hacer sencillas operaciones de stringsy numéricas para, por ejemplo, calcular el dígito verificador de la homoclave de un RFC. Y era muy lento. Es decir, no había realmente consultas a la base, de manera que pienso que no entraban en juego cuestiones de diseño.

// Saludos

[Osorio]

Bueno al margen de lo demás.

Si utilizamos DBExpress + DataSnap estas soluciones de traer conjuntos de datos con sus "hijos", y los hijos de sus hijos, y los hijos de los hijos de sus hijos, etc. se pueden implementar muy facil. Lo mejor es que no importa si el motor lo soporta o no.

Mas o menos ventajas? no se.

Saludos.

[[poliburro]]

Empezado por Osorio

Bueno al margen de lo demás.

Si utilizamos DBExpress + DataSnap estas soluciones de traer conjuntos de datos con sus "hijos", y los hijos de sus hijos, y los hijos de los hijos de sus hijos, etc. se pueden implementar muy facil. Lo mejor es que no importa si el motor lo soporta o no.

Mas o menos ventajas? no se.

Saludos.

Personalmente uso más ADO que DbExpress así que si te animas a compartir como se hace con esos componentes sería muy interesante y útil para la biblioteca de técnicas. Saludox

[Osorio]

Así de rapidito hice un pequeñito ejemplo con DBExpress pero sin dataSnap para ilustrar lo que me pasó por la mente cuando vi el tema.

Para los que quieran profundizar en el tema pueden ver:

La cara oculta de delphi 6: Paginas 705-707 para empezar.

Si esto no pega con el tema de conversación, ehhh. Bueno, a alguien le servirá.

Saludos.

[[Al González]]

Román, poliburro ya había aclarado el asunto de los datos repetidos.

Empezado por poliburro

Siguiendo el ejemplo que he posteado en mi blog, si tienes las tablas de encabezado de venta, detalle de venta e información de clientes. devolver toda esa información como un solo join normalito te genera una tabla con la siguiente estructura:

filasdatoscliente, datosencabezadoventa, partidadeventa1
filasdatoscliente, datosencabezadoventa, partidadeventa2
filasdatoscliente, datosencabezadoventa, partidadeventa3
...........
filasdatoscliente, datosencabezadoventa, partidadeventaN

como puedes observar, hacer uso de joins para devolverver toda esa información agrupada es sumamente infeciente pues vas a devolver un recordset con información duplicada y que te exigirá seprarla en tu código para mostrarla en los diferentes repositorios.

Casi, ya no recordaba aquellas opiniones que citaste de nuestro compañero (creo que ya no tengo memoria para ciertas cosas).

Edgar, aunque pudiera, eliminar la referencia no tendría ningún sentido. Además no cambia mi deseo de que visiten tu bitácora, yo encuentro valiosa la información que ahí compartes.

En cuanto a la sorprendente acusación de censura, pues ni qué decir.

[roman]

Empezado por Al González

Román, poliburro ya había aclarado el asunto de los datos repetidos.

Sí, tienes razón. Y no culpo a poliburro, sino a mi mismo Por alguna razón, no fue sino hasta que leí el comentario de RONPABLO que cai en la cuenta.

// Saludos

[[poliburro]]

Empezado por Al González

Edgar, aunque pudiera, eliminar la referencia no tendría ningún sentido. Además no cambia mi deseo de que visiten tu bitácora, yo encuentro valiosa la información que ahí compartes.

En cuanto a la sorprendente acusación de censura, pues ni qué decir.

Amigo, esa fué precisamente mi percepción a lo que mencionaste sobre mi actitud con relación a firebird. De ahí que te dijera que si lo considerabas a bien podrías eliminar la referencia a mi artículo. Si estoy errado en la percepción retiro lo dicho.