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

[[RONPABLO]]

Empezado por poliburro

Por que se toman tan a personal una crítica a firebird? por qué les cuesta tanto aceptar las críticas contra ese motor? deberían ser tan faciles de aceptar como las que hacen contra otras tecnologias....

Tal vez por la misma razón que tu te empeñas en decir que SQL Server puede hacer de otra forma lo que firibird hace, osea le quitas importancia a las ventajas de firebird sobre SQL Server porque lo puedes hacer de otra forma, lo mismo me pasa a mi, le quito importancia a que no pueda tener varios ResulSets en firebird porque lo puedo hacer de otra forma y generalmente realizando la misma cantidad de trabajo, a veces un poco más a veces un poco menos.

[[poliburro]]

Empezado por RONPABLO

Tal vez por la misma razón que tu te empeñas en decir que SQL Server puede hacer de otra forma lo

Pero no solo he mencionado a SQL server, también he mencionado a mysql, postgresql, oracle y db2 que son los motores de bases de datos que utilizo.....

Insisto... como lo mencioné en un hilo que cita casimiro.

Adolecer de estas características no la hacen un mal motor, al contrario sigue siendo una excelente opción para nuestros desarrollos, tanto como lo es access o paradox o dbase. Pero aceptando que tiene limitantes no deberia compararse con los grandes. (Oracle, Postgress, MsSql,Db2, Informix)

Firebird no es malo. al contrario es una excelente opción como lo pueden ser otros motores como access o paradox o dbase o mysql, pero eso de equipararlo a cualquiera de los grandes me parece una necedad.

Claro ese es mi punto de vista... no es la verdad absoluta. Como ha querido desde un inicio hacerlo ver aquí Casimiro tergiversando mis comentarios... o en el colmo de la censura Al gonzalez acusandome de tener una "actitud inquina" contra Firebird. como si para una crítica fuera necesario sentir simpatia por el objeto de las críticas...

[roman]

Empezado por RONPABLO

P
Imagina que en un llamado a un procedimiento se trae 3 DataSets, uno es encuestas, el segundo es preguntas de la encuesta y el tercer DataSet trae las respuestas dadas a cada pregunta, se trae únicamente los datos que se van a usar para no sobrecargar la conexión a red, estos DataSet en .Net se pueden tomar como tablas en memoria y hacer una especie de maestro detalle donde al seleccionar en un grid una de las encuestas me muestre en otro las preguntas ofrecidas y el total de respuestas por preguntas en otro grid,

Mmm. Creo que ahora lo veo más claro. Usar joins ocasionaría el viaje de datos repetidos del servidor al cliente.

Gracias

// Saludos

[roman]

Empezado por poliburro

o en el colmo de la censura

Nada más para aclarar a quienes en un futuro pudieran leer este desafortunado comentario. No ha habido ni mucha ni poca censura en este hilo, como no la hay en el Club en general.

// Saludos

[[poliburro]]

Empezado por roman

Nada más para aclarar a quienes en un futuro pudieran leer este desafortunado comentario. No ha habido ni mucha ni poca censura en este hilo, como no la hay en el Club en general.

// Saludos

No fué hacia Club Delphi como tal... sino a Al en particular... Aquí, el sitio como tal nunca me ha censurado. Aclaro mi desafortunado comentario....

[Casimiro Notevi]

Empezado por poliburro

Como ha querido desde un inicio hacerlo ver aquí Casimiro tergiversando mis comentarios...

¿Qué comentarios he tergiversado?

[roman]

Bueno, en lo personal, tampoco pienso que Al haya manifestado ningún tipo de censura.

De todas formas, propongo que no sigamos enfrascándonos en un debate en el que cada cual tiene sus posiciones muy asentadas e inamovibles.

// Saludos

[ecfisa]

Empezado por poliburro

Firebird no es malo. al contrario es una excelente opción como lo pueden ser otros motores como access o paradox o dbase o mysql, pero eso de equipararlo a cualquiera de los grandes me parece una necedad.

Hola.

Estoy de acuerdo, Firebird o MySQL no son rivales para, por ejemplo, un Oracle.

Pero personalmente opino que poner en el mismo plano a Firebird o MySQL con Paradox, DBase o Access es también un despropósito.

Saludos.

[[poliburro]]

Empezado por Casimiro Notevi

¿Qué comentarios he tergiversado?

por ejemplo aquí: http://clubdelphi.com/foros/showpost...7&postcount=41


o aquí: http://clubdelphi.com/foros/showpost...2&postcount=45

o aquí http://clubdelphi.com/foros/showpost...79&postcount=7 cuando en realidad el que lo comenzó fuiste tu aquí http://clubdelphi.com/foros/showpost...73&postcount=4 a pesar de que aclaré que no quería debatir aquí: http://clubdelphi.com/foros/showpost...75&postcount=6 aclarando que no me gusta firebird y a pesar de ello me acusas de incongruente aquí : http://clubdelphi.com/foros/showpost...&postcount=117

[[RONPABLO]]

Empezado por poliburro

Pero no solo he mencionado a SQL server, también he mencionado a mysql, postgresql, oracle y db2 que son los motores de bases de datos que utilizo.....

Insisto... como lo mencioné en un hilo que cita casimiro.

[/i]

Firebird no es malo. al contrario es una excelente opción como lo pueden ser otros motores como access o paradox o dbase o mysql, pero eso de equipararlo a cualquiera de los grandes me parece una necedad.

Claro ese es mi punto de vista... no es la verdad absoluta. Como ha querido desde un inicio hacerlo ver aquí Casimiro tergiversando mis comentarios... o en el colmo de la censura Al gonzalez acusandome de tener una "actitud inquina" contra Firebird. como si para una crítica fuera necesario sentir simpatia por el objeto de las críticas...

Claro y has defendido los procedimientos almacenados MySQL cosa que una gran cantidad se queja, yo personalmente empece a usar firbird después de pasar de Paradox a MySQL, y dicho paso fue desastroso, trabajaba más lento las mismas instrucciones en MySQL que en Paradox, comía más recursos y para rematar en ese momento la integridad referencial solo se podía en una arquitectura y al pasarnos a dicha arquitectura fue aun más lenta las cosas, ya no hablar de procedimientos almacenados o disparadores que no tenía en ese momento, después de mucho probar y probar abandonamos la idea de MySQL y nos pasamos a Firebird y y para mis necesidades que eran mayores a las de un Paradox o un Excel fue genial, unos años después por otro proyecto nos toco trabajar en MS SQL Server y personalmente me acuerdo que en ese tiempo decía "lo único que me gusta de MS es SQL Server y Age Of Empires", hoy en día también me gusta algo el C#... Ahora regresando al punto muy probablemente vas a querer ver que cosas hacía yo para que me fuera más mal con MySQL que con Paradox a tal punto que lo aborrecí y muy probablemente pensarás que hice las cosas muy mal para llegar a decir que MySQL era extramadamente lento, pues es eso, cuando dices algo sobre Firebird y lo dices con gente que trabaja con él todo él día pensarán que tus apreciaciones son más subjetivas que basadas en hechos, ya que las cosas que le criticas son cosas que hemos aprendido a manejar de otra forma, y como digo yo cuando trabajé con MS SQL Server extrañé mucho el uso del Suspend de firebird y ahora retomando este hilo también el no poder usar los procedimientos almacenados como consultas es algo que para mi es un punto muy malo de SQL Server ya que es demasiado útil, pero como no lo has usado no notas lo importante que es.

[[poliburro]]

Empezado por ecfisa

Hola.

Pero personalmente opino que poner en el mismo plano a Firebird o MySQL con Paradox, DBase o Access es también un despropósito.

Saludos.

En esto estoy deacuerdo, probablemente he caido en la exageración al mencionarlo junto con paradox o dbase o access. Podríamos decir que está entonces en un punto intermedio entre los grandes y los pequeños?

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

ahora retomando este hilo también el no poder usar los procedimientos almacenados como consultas es algo que para mi es un punto muy malo de SQL Server ya que es demasiado útil, pero como no lo has usado no notas lo importante que es.

esto es cierto... nunca he usado procedimientos almacenados como consultas. no puedo opinar sobre su utilidad o inutilidad.

sobre mysql... pues ahí si creo que dependen muchos factores. Diseño de la base de datos, tuning, hardware, etc..

tengo un sistema funcionando en línea con múltiples usuarios dode una de las tablas que consulto con dos millones de registros me responde en décimas de segundos. A mi me ha funciondo muy bien y estoy a gusto aunque me guste más trabajr en Oracle o Db2 o PostgreSql, mysql cumple las funciones que le doy muy bien...

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

[ecfisa]

Empezado por poliburro

En esto estoy deacuerdo, probablemente he caido en la exageración al mencionarlo junto con paradox o dbase o access. Podríamos decir que está entonces en un punto intermedio entre los grandes y los pequeños?

Desde mi humilde opinión, es el segmento donde los ubicaría.

Saludos.

[[RONPABLO]]

Empezado por poliburro

esto es cierto... nunca he usado procedimientos almacenados como consultas. no puedo opinar sobre su utilidad o inutilidad.

sobre mysql... pues ahí si creo que dependen muchos factores. Diseño de la base de datos, tuning, hardware, etc..

tengo un sistema funcionando en línea con múltiples usuarios dode una de las tablas que consulto con dos millones de registros me responde en décimas de segundos. A mi me ha funciondo muy bien y estoy a gusto aunque me guste más trabajr en Oracle o Db2 o PostgreSql, mysql cumple las funciones que le doy muy bien...

La aplicación que en su momento estuvo potenciada por MySQL hoy en día está en clientes que han llegado a tener más de 2 millones de registros en una tabla de control asistencia de citas, al ver las citas de un día no se nota ni el pestañeo y es muy poco lo que he cambiado de código ahora que usa Firebird a cuando usó MySQL y en ese momento con nuestros primeros clientes "grandes" y con unos 100mil registros se llegó a demorar 15 segundos y es un punto crítico... personalmente creo que hice muchas cosas malas para que se demorará tanto tiempo.

[[poliburro]]

Empezado por RONPABLO

personalmente creo que hice muchas cosas malas para que se demorará tanto tiempo.

más que cosas malas tiene que ver con la parte de "tuning" y aprovechamiento de las fascilidadades del motor. supongo que al conocer mejor firebird aprovechaste sus características y al conocer un poco menos mysql desaprovechaste algunas de las que tiene... En lo personal me gusta mucho trabajar en bases de datos, de hecho aspiro a ser un día DBA más que programador, aunque claro, programar es algo que también me apasiona

[Casimiro Notevi]

Bueno, amigo, yo no veo que haya tergiversado nada, pero si lo crees así, lo lamento.

[cointec]

Empezado por RONPABLO

La aplicación que en su momento estuvo potenciada por MySQL hoy en día está en clientes que han llegado a tener más de 2 millones de registros en una tabla de control asistencia de citas, al ver las citas de un día no se nota ni el pestañeo y es muy poco lo que he cambiado de código ahora que usa Firebird a cuando usó MySQL y en ese momento con nuestros primeros clientes "grandes" y con unos 100mil registros se llegó a demorar 15 segundos y es un punto crítico... personalmente creo que hice muchas cosas malas para que se demorará tanto tiempo.

Hola, nosotros tenemos tablas con 60 o más millones de registros y el acceso a ellas es rápido, por lo que no creo que el problema dependa de firebird. Si tarda 15 segundos, no está utilizando índices. Creo que deberías revisar el plan de ejecución de las consultas.