Teoría y Práctica sobre Firebird
6 octubre 2017
GENERAL administración, configuración, instalación, verificación Deja un comentario
La documentación para empezar a usar rápidamente Firebird 3 se encuentra disponible (en inglés) y la puedes descargar desde:
En ese documento encontrarás los siguientes temas:
Artículos relacionados:
3 diciembre 2014
GENERAL bases de datos, configuración, FIREBIRD.CONF Deja un comentario
La empresa IBSurgeon desarrolla programas utilitarios para ser usados con Firebird (algunos son gratuitos) y entre sus colaboraciones gratis se encuentran archivos de configuración optimizados.
Estos archivos de configuración optimizados están diseñados para ser usados con cualquiera de las principales arquitecturas (SuperServer, Classic, SuperClassic).
Ahora ya está también disponible el archivo de configuración optimizado para Firebird 3.0, beta 1. Pero también hay archivos de configuración optimizados para versiones anteriores del Firebird.
Los pasos a seguir son los siguientes:
1. Asegúrate de que nadie esté conectado a una Base de Datos, o sea que nadie esté usando al Servidor del Firebird
2. Detén el Servidor del Firebird
3. Entra en la carpeta donde has instalado al Firebird, por ejemplo en:
C:\ARCHIVOS DE PROGRAMA\FIREBIRD\FIREBIRD_2_5\
4. Haz una copia de seguridad del archivo FIREBIRD.CONF, ¡¡¡no te olvides de este paso!!!.
5. Cámbiale el nombre al archivo FIREBIRD.CONF, por ejemplo como FIREBIRD.CONF.ANTERIOR
6. Descarga el archivo FIREBIRD.CONF optimizado que corresponde a tu computadora, desde:
http://ib-aid.com/en/optimized-firebird-configuration/
7. Copia el archivo descargado a la carpeta donde se encuentra tu Firebird, por ejemplo, en:
C:\ARCHIVOS DE PROGRAMA\FIREBIRD\FIREBIRD_2_5\
8. Cámbiale el nombre a tu archivo descargado, para que pase a llamarse FIREBIRD.CONF
9. Reinicia el Servidor del Firebird
10. Eso es todo, a partir de este momento el Firebird estará usando al nuevo archivo de configuración
IMPORTANTE:
Es muy probable que luego de empezar a usar el archivo de configuración del Firebird optimizado notes una mejoría en el rendimiento de tus bases de datos, pero si ese no es el caso siempre puedes seguir usando tu archivo de configuración anterior, para ello: a) detén el Servidor del Firebird, b) borra el archivo FIREBIRD.CONF, c) renombra a tu archivo de configuración anterior como FIREBIRD.CONF, d) reinicia el Servidor del Firebird
Artículos relacionados:
9 diciembre 2013
Diseño de bases de datos auxiliares, configuración, diseño, maestras, movimientos, tablas, trigger 11 comentarios
Cuando diseñamos una Base de Datos normalmente creamos cuatro tipos de tablas:
Las tablas de configuración servirán para guardar datos que ayudarán a personalizar la aplicación relacionada.
Las tablas maestras servirán para guardar datos que luego usarán las tablas de movimientos.
Las tablas de movimientos servirán para guardar lo que ocurre en la operación normal de la empresa u organización, sus actividades diarias. A su vez se clasifican en cabecera y en detalle.
Las tablas auxiliares servirán para guardar datos temporales.
En las tablas de movimientos siempre tenemos una columna donde guardamos la fecha del movimiento, así que no es problema conocer las fechas cuando las necesitamos.
Pero eso muchas veces no ocurre con las tablas maestras, en ellas no se suelen guardar las fechas. Y puede ser muy necesario conocerlas.
Ejemplo:
Tenemos una tabla maestra de CLIENTES donde entre otros datos guardamos el Identificador del Cliente, su Nombre, su Dirección, su Teléfono. Y una tabla cabecera de VENTAS donde guardamos el Identificador de la Venta, el Identificador del Cliente, el Número de la Factura, la Fecha de la venta y otros datos.
Le hacemos una venta al cliente Juan Pérez, e imprimimos la Factura Número «001-002-3456789» que corresponde a esa venta. En ella consta que la Dirección de Juan Pérez es «Colón 12345» y que su teléfono es el «0123-456789». Todo bien hasta ahí, ningún problema, se va Juan Pérez con su Factura.
Un tiempo después regresa Juan Pérez, le hacemos otra venta, pero nos dice que se mudó y que por lo tanto se cambió su Dirección, su Teléfono y hasta su Localidad. Así que ahora le imprimimos la Factura Número «001-002-9876543» que corresponde a esta última venta, la nueva Dirección es «Spartacus 44444» y el nuevo teléfono es el «0333-555555». Todo bien hasta ahí, ningún problema, se va Juan Pérez con su Factura.
Pero …. luego surge el problema.
Hay una auditoría, el ente recaudador de impuestos hace un control cruzado entre las Facturas de Juan Pérez y nuestras Facturas y al consultar la Factura «001-002-3456789» le dice que la Dirección es «Spartacus 44444» y el Teléfono es «0333-555555» porque esos son los datos que tenemos guardados de Juan Pérez en nuestra Base de Datos actualmente.
Y está mal.
Está mal porque la Dirección que se imprimió en esa Factura era «Colón 12345». Y aunque pasen los años y Juan Pérez se mude de casa muchas veces siempre que consultemos los datos de la Factura Número «001-002-3456789» deberíamos ver que la Dirección es «Colón 12345». No la última Dirección que registramos en nuestra tabla de CLIENTES sino la Dirección original.
¿Cuál es la solución a este problema?
Tenemos tres alternativas, dos malas y una buena.
Una alternativa mala es restaurar un backup de la fecha de la primera venta a Juan Pérez para saber que Dirección teníamos guardada ese día.
Otra alternativa mala es guardar en la tabla cabecera de VENTAS la Dirección, el Teléfono, la Localidad, el Email y otros datos de Juan Pérez. Es cierto que eso nos aseguraría de imprimir siempre los datos correctos pero nuestra tabla no estaría normalizada y por lo tanto gastaríamos mucho más espacio en el disco duro que el necesario.
La alternativa buena es guardar en otra tabla, no en la tabla de CLIENTES sino en otra tabla, los cambios que se realicen a los datos de nuestros clientes. La estructura de esta tabla (la podríamos llamar CAMBIOS_CLIENTES) debería ser idéntica a la tabla CLIENTES pero tendría una columna más, esa columna adicional sería el Identificador de la tabla (el que usamos para su Primary Key).
La tabla CLIENTES (y por lo tanto la tabla CAMBIOS_CLIENTES) debe tener una columna donde se guarde el nombre del usuario que insertó la fila y otra columna donde se guarden la fecha y la hora de esa inserción.
De esta manera siempre podríamos saber cuales eran los datos de Juan Pérez en cualquier día de cualquier mes de cualquier año.
¿Cuál era la Dirección de Juan Pérez el día 12 de agosto de 2013?
El problema con las tablas maestras
Lo que vimos en el ejemplo anterior, con las ventas a Juan Pérez y sus cambios de direcciones se aplica a todas las tablas maestras. Cualquier tabla maestra que tengamos adolecerá del mismo problema si no tomamos las debidas precauciones: que estaremos viendo los últimos datos, no los datos que teníamos anteriormente. Y en muchos casos los que deberíamos ver son los datos que teníamos anteriormente.
Una Base de Datos que no puede ser retrotraída a cualquier instante anterior no está bien diseñada.
Es así de simple:
Un buen diseño implica más trabajo
Todo tiene sus ventajas y sus desventajas, nada es perfecto. Podemos tener una Base de Datos perfectamente diseñada que nos permita responder a cualquier pregunta en cualquier momento, pero eso demandará más de nuestro tiempo. Y es que por cada tabla maestra deberemos tener una tabla de CAMBIOS. Y por cada tabla maestra deberemos tener un trigger AFTER UPDATE que le inserte una fila a la tabla de CAMBIOS. Y a su vez nuestras consultas (SELECTs) serán más complicadas cuando involucren a las preguntas ¿quién? ¿cuándo? o ¿desde cuándo? y ¿hasta cuándo?
La diferencia entre tener una Base de Datos muy bien diseñada y una pobremente diseñada la verás el día que quieras venderle tu aplicación a gente que entiende de Informática. Mientras tus clientes sean ignorantes en temas informáticos podrás venderles casi cualquier cosa pero el tema es muy distinto cuando hablas con gente entendida. Por ejemplo si una empresa tiene un Departamento de Informática es seguro que tendrás que entrevistarte con los encargados y allí enseguida descubrirán tu pobre diseño.
Por lo tanto, si quieres vender tus aplicaciones a empresas de cualquier tamaño y no pasar vergüenza cuando hables con el personal informático, diseña tu Base de Datos de la mejor manera posible.
Artículos relacionados:
12 septiembre 2013
PROTECCIÓN Y SEGURIDAD Cliente, comandos, configuración, internet, seguridad, Servidor, START 21 comentarios
Aquí hay algunos ejemplos del uso de Zebedee con Firebird.
En estos dos artículos, habíamos visto para que sirve Zebedee y como usarlo. Ahora, para aclarar mejor el tema, algunos ejemplos:
Usando Zebedee con Firebird. Parte 2
Servidor
Línea de comandos
START ZEBEDEE -s localhost:3050
Usando un archivo de configuración
START ZEBEDEE -f SERVIDOR1.ZBD
Cliente
Línea de comandos
START ZEBEDEE 3051:99.999.999.99:3050
Usando un archivo de configuración
START ZEBEDEE -f CLIENTE.ZBD
Conexión con una Base de Datos Firebird
CONNECT localhost/3051:E:\BASESDATOS\MiBase.FDB USER SYSDBA PASSWORD masterkey;
NOTAS:
Artículos relacionados:
Proteger a las bases de datos visibles en Internet
Usando Zebedee con Firebird. Parte 2
Firebird SQL 
Comentarios recientes