Firebird 3.0 Quick Start Guide

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:

Firebird 3. Quick Start Guide

En ese documento encontrarás los siguientes temas:

  • Instalación
  • Verificación de que la instalación fue realizada correctamente
  • Ubicaciones por defecto de los componentes de Firebird 3
  • Configuración del Servidor
  • Administración del Servidor
  • Conexiones a bases de datos
  • Backups

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

 

Anuncios

Descargar gratis archivos de configuración optimizados

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:

El índice del blog Firebird21

El foro del blog Firebird21

 

 

La problemática de las tablas maestras

9 comentarios

Cuando diseñamos una Base de Datos normalmente creamos cuatro tipos de tablas:

  • Configuración
  • Maestras
  • Movimientos
  • Auxiliares

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?

  1. Buscamos en la tabla CAMBIOS_CLIENTES la fila más nueva que corresponda a Juan Pérez y que su fecha sea 12 de agosto de 2013 o anterior.
  2. Si la encontramos, esa es la Dirección de Juan Pérez el día 12 de agosto de 2013
  3. Si no la encontramos, buscamos en la tabla CLIENTES cual es la Dirección que originalmente tenía Juan Pérez
  4. Si esa fila fue insertada el día 12 de agosto de 2013 o antes, esa es la respuesta buscada
  5. Si la fila fue insertada posteriormente al 12 de agosto de 2013 entonces Juan Pérez aún no era nuestro cliente ese día y por lo tanto no podemos saber cual era su Dirección.

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:

  • Si yo necesito recurrir a un backup para que una consulta me muestre los datos correctos entonces mi Base de Datos está mal diseñada. Nada que discutir.
  • Si las tablas no están normalizadas entonces mi Base de Datos está mal diseñada. Nada que discutir.

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:

El índice del blog Firebird21

Ejemplos del uso de Zebedee con Firebird

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

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:

  1. En la computadora donde se encuentra el Servidor de Zebedee debe estar abierto el puerto 11965
  2. Las demás computadoras no necesitan (y no deberían) tener puertos abiertos
  3. Cualquier usuario puede conectarse, no solamente SYSDBA, por supuesto que con sus nombres y passwords correctos
  4. No es obligatorio escribir el comando START, pero si no se lo escribe entonces la ventana “Símbolo del sistema” se queda congelada. Zebedee funciona igual, pero esas ventanas congeladas no les gustan a los usuarios
  5. Las computadoras Cliente deben poder acceder a la computadora Servidor. Eso significa que la IP del Servidor debe ser pública, de una VPN como Hamachi o encontrarse en una red local
  6. No suele justificarse usar Zebedee en una red local, porque el tiempo que se gana al enviar los datos comprimidos se pierde al comprimir y descomprimir esos datos. Se justificaría su uso si aún tratándose de una red local hay computadoras que no son confiables
  7. Si se usa un archivo de configuración, ese archivo no debe encontrarse en una carpeta compartida o cualquiera podría modificarlo a su antojo
  8. Si la conexión con el Servidor de Firebird se realiza a través de Internet entonces usar Zebedee (o algún programa similar) es un requisito ineludible

Artículos relacionados:

Proteger a las bases de datos visibles en Internet

Usando Zebedee con Firebird

Usando Zebedee con Firebird. Parte 2

El índice del blog Firebird21