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.

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.



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

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

Gracias :)

// Saludos

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

¿Qué comentarios he tergiversado? :confused:

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

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.

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

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.

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?

Román, poliburro ya había aclarado el asunto de los datos repetidos. :)
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. :(

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

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

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.

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

Saludos.

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.

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 :)

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

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.

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

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

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.

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.

exacto ^\||/

As bajo la manga ...
 

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

¡Ah! Pues para eso existe wayback machine :)

// Saludos

Investigación RDB$DB_KEY
 

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

Hola!!

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

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:

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.

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!