FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#21
|
||||
|
||||
Cita:
. |
#22
|
||||
|
||||
Cita:
Seguridad: Las contraseñas son de ocho caracteres en la práctica. No existe un método nativo para hacer conexiones por SSL. Usuarios a nivel de base de datos. Limitar los dominios sobre los que puede iniciar sesión. Comparado con las características de seguridad de Postgre, Firebird se queda como un juguete para niños. Procedimientos almacenados: Nuevamente, comparado con Postgre, se queda como un juguete. Uso de red: Sí, en comparación (nuevamente ) utiliza mucha banda. Además el protocolo es poco tolerante a errores de conexión, como la pérdida de datos o micro-cortes en la conexión. Rutinas de Datos: Sí. Por ejemplo, no sé si existe aún una rutina para obtener el hast MD5 o SHA1 de un dato. Nuevamente, en comparación con Postgre se queda corto. No es que quiera decir que Firebird debe ser Postgre. Dios no lo quiera. Para eso ya existe Postgre. Sino que todo esto te lo digo como argumento del por qué creo que Firebird está un poco atrás para poder competir con Postgre para captar esta estampida de desarrolladores. Lo que sí me encantaría ver para la próxima versión de Firebird (3.0), es que se mejorará los aspectos de la seguridad y mejor tolerancia a errores de red. Eso para mí es lo más importante. Para el resto, sino necesitas de avanzados procedimientos almacenados y un millón de rutinas de datos, Firebird es una maravilla y me encanta. Desearía verlo más implementado en hosting y frameworks para desarrollo de aplicaciones . Saludos, Chris |
#23
|
||||
|
||||
No entendí Cuáles aspectos Jhonny?
|
#24
|
||||
|
||||
* Un mejor lenguaje para la programación de procedimientos almacenados.
* Agregar más rutinas para el procesamiento de datos. Diría que esos dos, además de la lentitud en los procedimientos almacenados que comenta roman y que no me parece completamente libre, al ponerle tantas "trabas" a su licencia.
__________________
Lecciones de mi Madre. Tema: modificación del comportamiento, "Pará de actuar como tu padre!" http://www.purodelphi.com/ http://www.nosolodelphi.com/ |
#25
|
||||
|
||||
No estoy de acuerdo, pero aunque lo estuviese, ¿no estamos hablando de mysql?, ¿a qué viene comparar ahora con postgresql?
|
#26
|
||||
|
||||
Cita:
Saludos, Chris |
#27
|
||||
|
||||
¿A qué se refieren con esto? Porque si se refieren a funciones nativas me parece que no es para nada una carencia de mysql. Por el contrario, cuenta con muchas funciones que en firebird debes agregarlas mediante udfs.
// Saludos |
#28
|
||||
|
||||
Bueno, Firebird hoy en día tiene muchas funciones nativas, que antes había que agregarlas por UDFs, pero que ya no... tendríamos que sacar un listado de las que tiene MySQl y determinar esto comparado realmente. Por otro lado y ya que lo mencionas, no se si... ¿MySQL tiene la posibilidad de agregarle más funciones, como lo hace Firebird con las UDFs o algo parecido?
__________________
Lecciones de mi Madre. Tema: modificación del comportamiento, "Pará de actuar como tu padre!" http://www.purodelphi.com/ http://www.nosolodelphi.com/ |
#29
|
||||
|
||||
No lo creo, y si lo tiene debe ser desastroso, igual que los procedimientos almacenados.
// Saludos |
#30
|
|||
|
|||
Cita:
y .... me encanta firebird por su facilidad de cambiar algunas cosas, facilidad de transportar la base de datos, estabilidad Última edición por ASAPLTDA fecha: 29-09-2011 a las 22:48:52. |
#31
|
||||||
|
||||||
Bueno, si.. es un pedido que se viene haciendo pero si fuera por vos Chris entonces quedate con tu queridito PostgreSQL. ¡Vaya si algunos a algunos les encanta seguir tirando leña sobre este tema! Ya dijeron que para FB 3.0 habrán mejorado e implementado mejoras en este aspecto. ¿No te podés aguantar un poquito?
Si en verdad Firebird fuera tan insegura... ¿Porqué se sigue utilizando? Ponete a leer los casos de éxito que está publicando FB y te darás cuenta de que en muchos aspectos se prefiere FB por incluso a Oracle. Cita:
¿Se me permite reir?... ¡Por Dios! Si hay algo que enorgullecerse del buen equipo de FB es que con cada liberación se mejora entre un 33% a 50% respecto a la anterior en la eficiencia en el uso y tráfico de red. Desde FB 2.x FB cuenta con un amplio abanico, y además uno puede extenderse gracias a UDF. ¿Te parece que son pocas? ¿Y cuáles más? ¿Cuáles crees que debería tener para ser superior, y estar en lo más top de lo top? Cita:
Cita:
Cita:
Cita:
Un motor es un motor... ¿Para que meterle más, y más.... rutinas, funciones? ¿TODAS te hacen falta? Seamos más equilibrados, lo que hace bien el motor déjaselo a el, para el resto está Mastercard; este... el Lenguaje de programación X y la aplicación que uno le desarrolle. No le pidas a un motor de base de datos que tenga incorporada una biblioteca para trabajar con redes neuronales, caso extremis. Cita:
Y que mejor saber que los avances del proyecto PostgreSQL se están amesetando y FB viene ganando más adeptos. No hace falta que la gente de MySQL se venga; ya se está viniendo la gente de PostgreSQL que reconoce que tienen un elefante pesado y no saben como seguir avanzando sin darle de comer más. Bueno, eso si te lo permito. Allí si te doy muchísima más razón. Le falta penetración en ese mercado. Saludos, |
#32
|
||||
|
||||
Delphius, noto que siempre recalcas en mis opiniones. Creo que te debo caer mal :P
Hombre, no sugiriendo que uno sea mejor que el otro. Cada uno de los motores tiene lo suyo y su ámbito óptimo. No elegirías Postgre o Firebird para manejar una simple agenda de contactos. Tampoco usarías SQLite para manejar un sitio como Tweeter. No estoy pidiendo que Firebird sea Postgre. Lo repito. Tonto sería yo si pidiera a SQLite que fuera como Oracle. Pedir este tipo de cosas creo que solo los tontos lo hacen. Si SQLite tuviera todo lo de Oracle perderíamos ese maravilloso motor de datos liviano y ligero para llevar. Repito, cada base de datos tiene su nicho y es pericia del desarrollador elegir el motor más adecuado para el menester. Pieso que sería ingenuo de un desarrollador elegir siempre el mismo motor para própositos y usos muy, pero muy distintos. Por eso uno tiene que saber que tiene uno y que le falta al otro. La gente de Postgre que debe estar viniendo a FB, seguramente no supieron hacer una buena elección al principio, o tal vez no existía Firebird en ese entonces. Hace ya un par de años, se me encomendó elegir un nuevo motor de base de datos para un sistema ya existente. Descarté a MySQL por su licencia dual. También, aunque no lo creas, descarté a PostgreSQL porque era como utilizar un camión para mover una pala de tierra. Al final elegí Firebird y estoy, hasta el día de hoy, inmensamente contento con la elección. Se adapta como un guante a los requerimientos y jamás, pero jamás me ha dado problemas. Eso sí, no me atrevo a exponerlo a la internet. Sería relativamente rápido averiguar la clave de SYSDBA. Sí me encantaría ver mejoras en el motor de Firebird. En lo que respecta a la seguridad, procedimientos almacenados (siempre hay dónde mejorar) y optimización del uso de red (compresión y mayor tolerancia a errores son lo más importante). Al final, no tomes lo que he dicho como crítica a Firebird. Más bien tómalo como Features request que más que todo eso son. Saludos, Chris PD.: Si deseas crear una aplicación de tres capas, pero utilizando la arquitectura Cliente <-> Servidor (DB exclusivamente), debes utilizar procedimientos almacenados para la lógica de negocios. Para escribir la lógica es de gran ayuda tener un cuasi lenguaje de programación. Es ahí dónde es bueno que una base de datos disponga de buen soporte de procedimientos almacenados (en Postgre se usa Python). Última edición por Chris fecha: 30-09-2011 a las 06:07:44. |
#33
|
|||
|
|||
Hola,
Me parece que, excepto Delphius, soys un poco "fanboys" de Firebird. Firebird es una buena base de datos, pero para nada es la octava maravilla del mundo. Tiene limitaciones, tiene "problemas" (lo comentado por Delphius del consumo de ancho de banda o todo el tema seguridad), y estas cosas están aquí, y no lo podemos ignorar. Es más, al reconocer que hay estos problemas, se ayuda a mejorar el sistema evitándolos, ya sea con "workarounds" (por ejemplo el uso del Zedebee para comprimir ancho de banda y encriptar la conexión), o bien pidiendo a los desarrolladores que se solucionen estos inconvenientes. Yo hace relativamente poco que uso Firebird, un poco más de un año y medio. Antes había usado HypersonicDB (Java), MySQL y MS Access. Y sabeis cual fue la primera limitación que encontre a Firebird, que los anteriores motores de bases de datos tienen? Los campos numericos autoincrementales. Será una tontería, pero para mi siempre será mucho más fácil definir un campo cómo "id INT NOT NULL AUTO_INCREMENT" que no definirlo cómo "id INT NOT NULL" y después crear un trigger para añadir el valor incremental... |
#34
|
|||
|
|||
Me olvidaba, la falta de campos del tipo BOOLEAN tambien es un poco molesto... :P
|
#35
|
||||
|
||||
Para empezar, me gusta muchísimo PostgreSql y Firebird, y no tanto MySql.
El haber elegido usar firebird es porque por aquellos días había un grave problema con postgresql, era muy lento. Lo demás me encantaba, la verdad. Pero las pruebas que hice, estoy hablando de 1998/99 (no existía firebird, era interbase), resultaron abrumadoramente superior la velocidad de interbase sobre postgresql. Otro punto a favor de interbase (entre otros muchos) es que puedes desconectar el servidor (de la corriente eléctrica), o puedes resetear el equipo, y 'normalmente' nunca pasa nada, se recupera automáticamente como si no hubiese pasado nada. Resumiendo es rápido y seguro ante problemas físicos. Yo sé que postgresql es muy potente, que tiene características muy interesantes, no lo descarto para futuros proyectos, pero centrándonos en lo que trata este tema: mysql. Si tuviera que elegir entre mysql y firebird para lo que se usa hoy en día mysql (en la mayoría de casos), me parece mucho más acertado usar firebird, es mucho más pequeño, no consumo apenas recursos, es muy rápido, es muy seguro ante caídas/parones/desconexiones, etc. Fuera de internet, sin embargo, postgresql lo usaría para proyectos de gestión para empresas rivalizando también con firebird. Por ahí tengo una comparativa que hicieron hace años entre mysql, interbase, postresql y sapdb. Una de las pruebas que hicieron (además de las habituales de insertar muchos registros y haces cosas), fue la de conexiones persistentes y.... ya lo encontré, mejor pongo los enlaces al final de este texto. Ahí dicen frases como: * Mysql bajo pocas conexiones funcionó perfectamente, cumpliendo expectativas, pero no pudo con el Interbase en el tramo final. * Interbase se lleva el premio de base de datos ideal para servidor Internet. Hay que tener en cuenta que es de hace bastantes años, que todos han envolucionado, pero sirve de referencia para darnos cuenta que muchas veces son sensaciones, prejuicios, imagen, desconocimiento, etc. y lo que tenemos en nuestro cerebrito no siempre es la realidad de las cosas. La máquina de test es un Pentium III 800Mhz con 256Mb RAM y un disco IDE de 20Gb. (ya hace tiempo, sí) Aquí algunos datos que se ofrecen en la comparativa: Código:
Segundos en completar las 1000 peticiones MySQL PostgreSQL Interbase SAP DB 10p 312,66 752,74 225,30 305,31 10 325,22 943,40 212,42 300,03 20p 849,47 813,69 262,76 549,99 20 947,91 974,51 291,12 612,06 30p 1153,88 1620,00 377,75 763,76 30 1199,01 1468,79 408,23 806,18 40p Timeout Error 681,38 timeout 40 Timeout Error 683,29 timeout 50p Timeout Error timeout timeout 50 Timeout Error timeout timeout Peticiones servidas por segundo MySQL PostgreSQL Interbase SAP DB 10p 3,17 1,32 4,39 3,24 10 3,04 1,04 4,66 3,30 20p 1,17 1,21 3,77 1,80 20 1,04 1,01 3,40 1,62 30p 0,86 0,61 2,62 1,30 30 0,83 0,67 2,43 1,23 40p Timeout Error 1,45 timeout 40 Timeout Error 1,45 timeout 50p Timeout Error Timeout timeout 50 Timeout Error Timeout timeout Código:
Ratio de transferencia en Kb/seg MySQL PostgreSQL Interbase SAP DB 10p 763,40 317,09 1059,45 781,79 10 733,98 253,01 1208,55 795,54 20p 280,97 293,34 962,69 433,98 20 251,80 244,93 940,92 389,97 30p 206,85 147,34 664,13 312,52 30 199,07 162,50 658,69 296,07 40p Timeout Error 363,22 timeout 40 Timeout Error 402,41 timeout 50p Timeout Error timeout timeout 50 Timeout Error timeout timeout
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código Únete al grupo Teaming clubdelphi | Colabora mediante Paypal Última edición por Casimiro Notevi fecha: 30-09-2011 a las 16:33:11. |
#36
|
|||
|
|||
Cita:
Pero de las cosas que me gustaria tener en firebird seria por ejemplo los campos tipo %row, ejemplo mi archivo de clientes aunque no uso todos los campos prefiero decir campos %row select * from clientes into w_row_clientes en ves de : select codigo,nombre,direccion.... from clientes into :w_codigo, :w_nombre ............ por eso me daria facilidad de desarrollo de funciones/procedimientos enla base de datos funciones select cliente, f_get_nombrecliente(cliente) from mov_CXC where .... Manejo de selects tipo bases cubos de datos, aunque por ahi hay un ejemplo que lo hace select cliente,sum(ventas),mes from ventas, agrupado por cliente,(matriz(mes)) y el resultado fuera cliente,ventas_mes01. ventas_mes02... ahora muchas veces en la busqueda de una verdad inalcansable uno quiere que los procesos se hagan en la base de datos, otras veces se hagan en una capa intermedia, uno quiere que se haga con un lenguajes externo a la base de datos o un lenguaje interno a la base de datos creo de pronto como recomendo la ibm (as400) haga los procesos en la base de datos no la haga en los programas aunque la la base de datos de ibm maneja procedures/functions en lenguaje PLSQL o en lenguje externos RPG/COBOL/JAVA/...? hace muchos anos no los manejamos |
#37
|
||||
|
||||
Todas tienen cosas interesantes, característica que nos gustaría tener en las demás, realmente todas son magníficas.
¿Qué es eso de los campos %row?, ¿una especie de variable? Por cierto, aquí hay una buena comparativa entre postgresql y ms sql server, la hizo hace no mucho los de RedHat, usaron equipos bien potentes. Adivinad quién salió ganando la comparativa. Código:
Hardware: Database: 2 x HP ProLiant DL370 G6 Dual Socket, Quad Core (Total of 8 cores) Intel® Xeon® CPU W5580 @ 3.20GHz 48 GB RAM Driver: 1 x HP ProLiant DL580 G5 Quad Socket, Quad Core (Total of 16 cores) Intel® Xeon® CPU X7350 @ 2.93GHz 64 GB RAM Software: Linux: Red Hat Enterprise Linux 5.4 (2.6.18-164.el5) Database: Postgres Plus 8.3.8 Windows: Windows Server 2008 R2 Enterprise Database: SQL Server 2008 R2 |
#38
|
||||
|
||||
Cita:
Cita:
Si a veces la gente se fija una idea... // Saludos |
#39
|
||||
|
||||
Cita:
Saludos, Chris |
#40
|
|||
|
|||
Cita:
|
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
php con mysql a php con oracle | fede_prog | PHP | 2 | 12-07-2007 04:14:18 |
Problema al leer un fichero que empieza con ÿþ | Durbed | Varios | 4 | 19-06-2007 18:28:44 |
IB/FB o MySQL/PgSQL/Oracle...? | OSKR | Firebird e Interbase | 7 | 27-08-2005 21:43:58 |
Sintaxis SQL para campo que empieza por | istradlin | Conexión con bases de datos | 5 | 12-05-2005 16:26:04 |
...como empieza un mal dia... | Jure | Humor | 0 | 08-07-2004 19:07:43 |
|