Consejos para empezar con firebird

[[RONPABLO]]

Porque Firebird?

1. Es la versión evolucionada de InterBase 6.0 (la cual fue Open Soure), cuando otras bases de datos estaban dando sus primeros paso (MySQL, Postrgres y hasta el SQL server que antes del 2000 era una... mejor no digo), Interbase ya estaba en el mercado con procedimientos almacenados trigers entre otras cosas.

2. Recursos. para mi es muy agradable que una aplicación que haga tantas cosas solo ocupe tan poco espacio en Disco y consuma tan pocos recursos, permitiendo trabajar en equipos que otros ya dan por obsoletos.

3. Tan rápido como MySQL pero con la diferencia de que solo maneja una sola tecnologia (MySQL tiene InnoDB (la cual ya la compro Oracle y que al usar esta se pierde esa gran velocidad de MySQL, y otras 3 0 4 mas que no recuerdo).

4. Soporte a bases de datos extremadamente grandes sin perdida de rendimiento (Casimiro nos mostraba alguna vez la noticia donde habían bds Firebird por el orden de los teras), SQL Server en la versión shareware no permite pasar a mas de 2G y una limitación de usuarios simultáneos (creo que son 6, no recuerdo mucho, porfavor me corrigen).

5. Una gran cantidad de componentes nativos en productos Borland (recuerda que Firebird es la evolución de Interbase 6, el cual es de la borland), que productos Dephi por ejemplo.

6. Es Open Source y Free Distribution con licencia Mozilla (que no es lo mismo a GNU).

7. Corre en varios sistemas Operativos, yo lo he usado desde win95 hasta vista y en Linux Red Hat, Mandrake y Debian (Red Hat y Debian fueron pruebas que me salieron muy bien en mandrake fue para un proyecto).

8. Permite conectar a .Net, ASP, PHP, Delphi, C Builder y otros muchos mas.

Como todo tiene defectos pero desde mis necesidades son desde muy lejos mas los pro que los contra

[[Lepe]]

MySql, según dice su propia licencia, puedes vender tu programa, pero tienes que entregar el código fuente con él, si no lo haces debes pagar una licencia de 600 €.

Firebird es totalmente gratuito y OpenSource.

El hecho de que haya más preguntas que respuesta en el foro de Firebird, es bien obvio. La gente viene a hacer sus preguntas antes de mirar los manuales... porque estan en inglés. Si eres o quieres llamarte programador, el inglés tienes que manejarlo, por lo menos leer y comprender, (no hace falta pronunciar bien).

Como ya dije en otro hilo, en mi mes de vacaciones me leí unas 1.500 páginas de los manuales de Interbase, no necesitas nada más, quizás, alguna pregunta por "falta de experiencia", pero no tienes que saltar al foro a preguntar por el NETFILEDIR de paradox. Los manuales te dicen todo lo que necesitas saber. Lo aprendes de primera mano, rápidamente y siguiendo un hilo que tiene un objetivo. En el foro se responden dudas concretas, pero no se puede explicar "Todo".

Las maravillas de Firebird Vs Access podrían ser (desde mi punto de vista):
- Los SP, esos grandes desconocidos. Equivalentes en Access a pedir una consulta, recorrer los datos (en delphi) de esa consulta, haciendo cálculos, añadiendo campos LookUp, realizando sumas, etc, y aplicando filtros personalizados. Con Firebird, lo haces en la BBDD, después usas un simple TQuery con "Select * from NombreStoreProcedure(parametro entrada)"

- Informar a todos los ordenadores de una red de la inserción de un nuevo cliente, factura, etc. En access usas un Timer para refrescar los datos cada X segundos. En Firebird, al insertar un nuevo cliente, el servidor informa a todos los ordenadores, y simplemente tendrás que cerrar y abrir las consultas. Es algo más eficiente ¿no?

[roman]

En mi opinión, en este hilo se está perdiendo un poco la perspectiva de lo que originalmente se preguntó y se pone a FireBird como la solución única para cualquier situación.

Se les olvida que FireBird tiene una curva de aprendizaje bastante mayor que otros sistemas:

Empezado por Lepe

en mi mes de vacaciones me leí unas 1.500 páginas de los manuales

¡Mil quinientas páginas! ¡Y en vacaciones! ¿¡Para hacer una agenda!? ¡UNA AGENDA!

¿Para qué quiero procedimientos almacenados, disparadores y quién sabe cuantas cosas más para hacer una agenda?

No estoy diciendo que no haya que aprender FireBird, pero como bien dijo Caral

Empezado por Caral

Cuando se quiere hacer algo sencillo que te lleve un par de horas, totalmente funcional, yo usaria Access

No me cabe la menor duda que quien inició este hilo tiene capacidad más que sobrada para aprender FireBird (u Oracle si me apuran), y hacer su agenda con ello, pero creo que no es necesario siempre matar pulgas con cañones.

Tanto las respuestas de RONPABLO como de Lepe, son muy interesantes, y ambas dan un buen panorama de lo que es y puede ser FireBird; pero no estamos hablando en general ni tratando de encontrar la solución última para cualquier sistema. ¿Que MySQL obliga a dar el código fuente? Cierto, pero, ¿para una agenda de una amiga, es esto terrible? ¿Que MySql se alenta con tablas InnoDB? Cierto, pero esto sólo ocurre con inserciones y actualizaciones masivas y no sería el caso ni para una agenda ni para muchas aplicaciones.

En fin, es sólo una opinión. No pretendo descalificar las otras, sino simplemente mantener en perspectiva las cosas.

// Saludos

[[egostar]]

Hola de nuevo después de un largo fin de semana (ayer lunes fue día de asueto en México) en el cual me olvidé de todo, de cualquier contacto con mi computadora, de internet, de mi correo, de todo....., bueno, no de todo.

Quiero complementar lo dicho por Roman, sin lugar a dudas, una agenda se puede hacer hasta con Paradox (lo prefiero a Access), pero, si nos ponemos un poco pesados, hacerlo con firebird me parece una buena opción, de hecho yo estoy desarrollando una agenda (tambien para una amiga.... vaya, se me hace que se hace moda eso de agendas para las amigas).

Bueno, la cuestión es que después de haber terminado la agenda, a mi amiga se le ocurrió que con la agenda pudieramos generar muchas mas cosas, es decir, el llamado ToDo, generar documentos como contratos, invitaciones, etc... ya que la agenda proporciona la información relativa a sus contactos.

Desde un inicio decidí hacerlo con Firebird, y no por otra cosa sino para aprender a usarlo, yo siempre hice sistemas con Paradox, cosa que me viene muy bien ya que como ha dicho Caral, los sistemas que hago son muy sencillos y bastaba con mi base de datos por excelencia.

Ahora, Firebird y su curva de aprendizaje si tiene su tiempo, pero he visto que me permite cosas en las que Paradox requiere de mayor esfuerzo, por ejemplo su uso local o en red sin tener que batallar con el BDE entre otras cosas.

En concreto, quiero decir, que para aprender a usar firebird (o cualquier otra base) no hay como una aplicación que no es de misión crítica donde te puedes dar el lujo de cambiarla si no es lo que habias pensado.

Desde mi punto de vista, claro esta.

Saludos.

[Casimiro Noteví]

Yo también pienso que firebird es perfectamente válido para una aplicación sencilla, como una agenda. Tengo algunos programillas del estilo que usan firebird y no encuentro que sea nada complicado, la curva de aprendizaje es mínima, jamás he leído 1500 páginas de manuales, ni nada por el estilo, a fin de cuentas todo se resume en un "insert" cuando se da de alta un registro, un "delete" cuando se borra un registro, un "update" cuando se modifica un registro, un "select" cuando se consulta un registro, un select con parámetros para sacar un listado o consulta de varios registros y... se acabó, no hay más, escasamente 5 sencillas sentencias sql. No hace falta conocer nada más de firebird.
¿Qué se gana?, potencia, seguridad, rapidez, fiabilidad, estabilidad... ocupa poquitos recursos, se instala en un momento y no ocupa nada.
Incluso podemos poner la base de datos en otro ordenador y acceder por red, o en cualquier lugar del mundo y acceder por internet o ponerla en un ordenador con linux y compartirla sin problemas.

Ya, ya... ya sé que hablamos de una agenda personal Pero y si esa amiga decide un día comprar un portátil y resulta que viene con ubuntu el programita será fácilmente reescrito con Lazarus y la firebird y la base de datos no necesitan nada porque ya funcionarían en linux

Ya sé que soy un pesao, jeje

[[RONPABLO]]

En si la idea de hacerla agenda en Firebird fue desde un inicio de seoane ya que había oido de las ventajas de Firebird Embebido... desde mi punto de vista es la mejor opción para una agenda simple, ya que el servidor de la bd es una dll que puede estar al lado de la aplicación y la bd, sin tener que instalar nada en el equipo, y con la gran ventaja que si un día esa aplicación crece y necesita trabajo en red y que múltiples aplicaciones accedan a ella es solo instalar Firebird CS o SS.

Nota... El negocio en donde trabajo (y soy socio) empezó en base a una Agenda para un amigo, la cual poco a poco fue creciendo, de un momento a otro la velocidad era cada vez menor y también mayo el numero de corrupciones, la solución (para las corrupciones mas no para la velocidad) pasar a MySQL, ya para este tiempo varias personas usaban la agenda y no muchos tenían buenos equipos, nos demoramos 2 meses cambiando de Paradox a MySQL y en un mes ya estábamos buscando otra opción y encontramos Firebird. de entrada un instalador Menor a 5M, corría como servicio o se podía poner en el inicio en Win Me y menores, era lo mismo en lo de SQL que yo conocia, pero ademas habían Vistas, SPs, Triggers que poco a poco me vi usándolas y luego no entendía como trabaje tanto tiempo sin eso tan bueno

[TJose]

Hola

han visto SQLite http://www.sqlite.org/
Desde hace unos días estoy probando y se ve muy bien.

• Transactions are atomic, consistent, isolated, and durable (ACID) even after system crashes and power failures.
• Zero-configuration - no setup or administration needed.
• Implements most of SQL92. (Features not supported)
• A complete database is stored in a single disk file.
• Database files can be freely shared between machines with different byte orders.
• Supports databases up to 2 tebibytes (241 bytes) in size.
• Strings and BLOBs up to 2 gibibytes (231 bytes) in size.
• Small code footprint: less than 250KiB fully configured or less than 150KiB with optional features omitted.
• Faster than popular client/server database engines for most common operations.
• Simple, easy to use API.
• TCL bindings included. Bindings for many other languages available separately.
• Well-commented source code with over 95% test coverage.
• Self-contained: no external dependencies.
• Sources are in the public domain. Use for any purpose.

Hay un administrador (muy lindo y simple) disponible en http://sqliteadmin.orbmu2k.de/