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

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

[Casimiro Notevi]

Bueno, todo es relativo, lo más "rápido" es no tener triggers, stored procedures, claves foráneas, sólo un índice para buscar sobre el mismo, etc.
Cuantos más índices tengamos entonces más lento será porque tiene que actualizarlos todos, y así ocurre con todo, pero entonces tendriamos una tabla plana y punto.

[[mightydragonlor]]

Empezado por Casimiro Notevi

Bueno, todo es relativo, lo más "rápido" es no tener triggers, stored procedures, claves foráneas, sólo un índice para buscar sobre el mismo, etc.
Cuantos más índices tengamos entonces más lento será porque tiene que actualizarlos todos, y así ocurre con todo, pero entonces tendriamos una tabla plana y punto.

Exacto, para eso no se hace uso de un RDBMS.

[Casimiro Notevi]

exacto

[Gallosuarez]

Bueno, hasta para eso (agilizar algunas actualizaciones masivas e inserciones complejas sin utilizar índices) Firebird cuenta con el no tan conocido RDB$DB_KEY. Es una verdadera lástima que Claudio Valderrama, que hizo mucha de la investigación sobre este tema haya dado de baja su página web (http://www.cvalde.net/document/pract...of_the_rdb.htm). Sería bueno saber si alguien conserva alguna copia sobre todo esa investigación o en su defecto pedirle de favor a Claudio Valderra si puede proporcionar todo es información nuevamente.

Saludos,
Gerardo Suárez Trejo

[roman]

¡Ah! Pues para eso existe wayback machine

// Saludos

[Gallosuarez]

Roman:

Bueno, pues asunto solucionado. Gracias por el aporte ...
Por otro lado, como bien lo dice dicho artículo, los ejemplos pudieran ser escritos mas en forma de un "tutorial", de esta manera se ejemplifica mas su entendimiento.

Saludos,
Gerardo Suárez Trejo

[jachguate]

Hola!!

Recién estoy leyendo este largo hilo, por lo que no estoy enterado de todo su contenido aún

A medida que voy leyendo, y dado que he salido a bailar entre los mensajes, he encontrado un par de referencias que me gustaría comentar:

Empezado por roman

mientras que jachguate hace mucho tiempo que no se pasa por aquí y ni siquiera comenzó él el hilo.
...
Y tan apreciamos lo que jachguate dio en su momento al club, que sigue siendo moderador.

A la fecha sigo considerando al Club Delphi mi casa, o para ser más exacto, algo así como la casa de mis padres, de la cuál estoy separado por varios cientos de kilómetros de distancia y de igual manera visito poco, pero siempre que lo hago, lo hago con toda la confianza, sintiéndome tan bienvenido como siempre.

La decisión del equipo de mantener mi status de moderador es algo que también aprecio y agradezco, aunque no con poca pena, pues para nada realizo las funciones y tareas que los moderadores hacen para mantener la casa en orden y con buen funcionamiento.

Empezado por roman

Simplemente diré, que, más que defender un punto, da la impresión de que tienen cierto rencor por no haber visto aquí una recepción más abultada a la traducción del libro de Programación Paralela, un rencor, que ni siquiera sé si el propio Juan Antonio tiene.

Sobre esto, mi estimado roman, no comprendo exactamente a que te refieres, pero lejos de un rencor, lo que existe de mi parte es agradecimiento, a quien se tomó la molestia de publicar la noticia de la publicación del libro, y a los moderadores del club por permitir el espacio para que esta se realizara y permaneciera.

De entrada sé que el tema es bastante especializado y por tanto no genera demasiado movimiento a su alrededor –aunque dicho sea de paso, multi-hilos es el presente y el futuro de la computación–, además de que, debido a la falta de costumbre encontrar libros en español sobre Delphi, poco estamos acostumbrados a leer y dar la bienvenida a este tipo de materiales.

Un saludo cordial!