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

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

// Saludos

[marcoszorrilla]

Es lógico que supongas que el soporte xml en una base de datos no tiene importancia. Pues entiendo que lo haces desde el punto de hablar sin saber. Pronto escribiré un artículo en mi blog sobre el manejo de XML en una base de datos.

Y no amigo... un debate, sin importar lo álgido, mientras no exceda los límites del insulto es siempre benéfico para todas las partes.

No creo que tildar a alguien de hablar sin saber sea la mejor manera de entablar un debate, máxime cuando Casimiro no habla sin saber.

Un Saludo.

[[egostar]]

Bueno, cosas peores se han dicho aquí en los "debates" de la religión y de Apple, pero aún así, si vamos a ver con pinzas las palabras, pues....

Y en cuanto a las otra "larga lista" de cosas que no soporta firebird, leer xml o importar/exportar a excel, texto o csv... pues me parece ridículo, sin importancia, no es necesario (aunque hay utilidades de sobras para hacerlo) porque un RDBMS no tiene que dedicarse a esas cosas, tal y como dice mightydragonlor.

Pero al margen de todo esto, yo difiero un poco en relación a que una solución profesional y seria siempre sea una solución libre, para mi una solución "profesional y seria" es ofrecer todas las alternativas para que el cliente tenga en sus manos todos los panoramas. Una cosa son las preferencias y otra es ofrecer todas las alternativas y a partir de ahí dejarle ver los pros y los contras.

Y ésto por supuesto incluye a las bases de datos y sigo sosteniendo que la mejor base de datos es la que te permite hacer todo lo que necesitas, yo no veo el factor costo, eso al final es relativo, habrá clientes que paguen el costo de una base de datos costosa, habrá clientes que quieran una base de datos sin costo.

Y como dice Román, yo también quiero saber para que sirve lo propuesto en el título de este hilo.

Saludos

PD. Y que conste que mi aprecio tanto por Casimiro y por Poliburro es muy alto.

[Casimiro Noteví]

Empezado por movorack

...

Empezado por poliburro

Total y absolutamente concuerdo contigo. A lo largo de mi vida profesional mi apertura a usar el servidor de base de datos que se ajuste a los requerimientos de mis clientes es lo que me ha permitido conocer múltiples y variadas soluciones....

Estáis hablando de empresas que YA tienen instalado todo en windows, en ese caso es normal que no quieran cambiar, les da pánico.

Sobre el XML. Nadie ha dicho que no tenga sus especificaciones y sus normas y estándares. Lo que he dicho es que XML se usa para trapasar datos entre distintos programas (bases de datos/editores de textos/navegadores webs, etc.), pero el que un sistema de bases de datos RDBMS no tenga una función para leer o escribir ficheros XML no es importante. Suponiendo que firebird no lo tenga, hay muchas utilidades para importar/exportar datos XML con firebird, es más, se puede crear una UDF (función definida por el usuario), que es algo que sí tiene firebird... y ya tienes XML. Por eso digo que es algo ridículo y sin importancia. Ninguna base de datos va a ejecutar sentencias SQL contra un fichero de texto XML, sería ridículo, y si alguna lo hace... me parece más una curiosidad que algo práctico, pues debe ser ineficiente y lento a más no poder. Además de que entonces ¿para qué se usa una RDBMS?, ¿para trabajar con ficheritos de texto?

Empezado por egostar

yo difiero un poco en relación a que una solución profesional y seria siempre sea una solución libre, para mi una solución "profesional y seria" es ofrecer todas las alternativas para que el cliente tenga en sus manos todos los panoramas. Una cosa son las preferencias y otra es ofrecer todas las alternativas y a partir de ahí dejarle ver los pros y los contras.

No recuerdo haber dicho eso, lo que he dicho es que windows no es una solución seria y profesional.

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

[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

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