Consejos para empezar con firebird

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