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

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

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

[[maeyanes]]

Hola...

Empezado por cointec

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.

Creo que te confundiste, RONPABLO estaba hablando de MySQL y no de Firebird cuando se refería a que era lento.



Saludos...

[[RONPABLO]]

Empezado por maeyanes

Hola...



Creo que te confundiste, RONPABLO estaba hablando de MySQL y no de Firebird cuando se refería a que era lento.



Saludos...

Aja, además terminé diciendo que en ese tiempo (hace mucho), debí estar haciendo las cosas muy mal para tener esos resultados de tanta lentitud, creo que algo que mejoro la velocidad era que en ese momento en MySQL la integridad referencial no estaba muy bien implementada, cosa que de entrada en FIribird si que soportaba sin problemas, y aunque un una llave foránea no crea indices si mejora (percepción personal) la velocidad, algo similar a la indexación debe de hacer al crear dicha llave pienso yo

[Casimiro Notevi]

Claro, al crear una clave foránea se crea automáticamente un índice por ese campo.

[[mightydragonlor]]

Empezado por RONPABLO

y aunque un una llave foránea no crea indices si mejora (percepción personal) la velocidad, algo similar a la indexación debe de hacer al crear dicha llave pienso yo

Realmente no es así, si bien los índices son necesarios para optimizar el rendimiento, las llave foráneas hacen que sea mas lento, es decir, el motor tiene que comprobar que esa llave se cumpla, por esta razón una base de datos sin llaves foráneas da como resultado una mejora notable en velocidad, eso si, no tiene sentido usar un RDBMS si no le vas a sacar provecho, además que las claves foráneas son super importantes para mantener la integridad de la base de datos.

No hace mucho, una empresa consultora muy importante, asesoró a una empresa para la cual hacemos desarrollos, y una de las cosas que les dijo, es esto que les comento para una base de datos oracle 11g, algo que obviamente no estoy desacuerdo por lo antes mencionado.

Saludos.