El tipo de datos BOOLEAN en Firebird 3

6 comentarios

Un tipo de datos que siempre le faltó a Firebird fue el BOOLEAN… hasta ahora.

Desde siempre contábamos con los tipos de datos: SMALLINT, INTEGER, BIGINT, FLOAT, DOUBLE PRECISION, NUMERIC, DECIMAL, DATE, TIME, TIMESTAMP, CHAR, VARCHAR, BLOB, pero no contábamos con BOOLEAN, entonces si lo necesitábamos (algo muy frecuente al crear una tabla) lo simulábamos creando un dominio como el siguiente:

CREATE DOMAIN D_BOOLEAN AS
   CHAR(1)
      CHECK (VALUE = 'F' OR VALUE = 'T');

Funcionaba bien, claro que sí, pero no es realmente un tipo de datos BOOLEAN.

¿Por qué no?

Porque le faltan los predicados lógicos. Es decir las comparaciones por verdadero o falso.

Un ejemplo de lo que ahora podemos hacer:

UPDATE
   MiTabla
SET
   MiColumnaBoolean = (MiValor1 IS DISTINCT FROM MiValor2)

Una comparación puede darnos uno de estos tres resultados posibles:

  • Verdadero
  • Falso
  • Nulo o desconocido

(Recuerda que en SQL un valor nulo significa: “desconocido”)

En el ejemplo anterior, si MiValor1 es distinto de MiValor2 en MiColumnaBoolean se guardará Verdadero, ya que la condición se cumplió. Si alguno de esos valores era nulo entonces se guardará Desconocido (porque el resultado de comparar un valor desconocido con cualquier otro valor siempre es desconocido).

Valores posibles de una columna de tipo BOOLEAN

Si declaramos que una columna será de tipo BOOLEAN, en ella podremos guardar cualquiera de los siguientes valores:

  • TRUE
  • FALSE
  • UNKNOWN

TRUE significa “verdadero”, FALSE significa “falso” y UNKNOWN significa “desconocido”.

IMPORTANTE: podemos usar NULL o UNKNOWN, como nos guste más, ambas palabras son sinónimos y pueden usarse intercambiablemente, así que usar una u otra depende del gusto de cada quien.

El operador IS

Para hacer las comparaciones podemos usar el operador IS [NOT], escribiendo algo como:

MiColumna1 IS TRUE
MiColumna2 IS FALSE
MiColumna3 IS NOT TRUE
MiColumna4 IS NOT FALSE
MiColumna5 IS UNKNOWN
MiColumna6 IS NULL
MiColumna7 IS DISTINCT FROM MiColumna1

Los operadores de comparación

Además del operador IS que vimos en el apartado anterior, también podemos comparar con: “=”, “<“, “<=”, “>”, “>=”, “!=”, “<>”

Comparación abreviada

Cuando comparamos por “verdadero”, podemos escribir algo como:

WHERE
   MiColumnaBoolean1

Fíjate que no escribimos MiColumnaBoolean1 IS TRUE, ya que el IS TRUE está implícito. Podemos escribirlo, si queremos, pero no es necesario. Similarmente, para comparar con “falso” podríamos escribir:

WHERE
   NOT MiColumnaBoolean1

En este caso, la condición se cumplirá cuando el valor guardado en la columna MiColumnaBoolean1 sea “falso”. También podríamos haber escrito: MiColumnaBoolean1 IS FALSE, al igual que antes, es cuestión de gustos usar una forma u otra.

Valores devueltos por el comando SELECT

Cuando en la lista de columnas que muestra nuestro SELECT existe alguna de tipo BOOLEAN, los valores que podemos ver son los siguientes:

<true>

<false>

<null>

Convirtiendo un tipo de datos BOOLEAN a CHAR o VARCHAR

Solamente podemos convertir el valor de una columna de tipo BOOLEAN a CHAR o a VARCHAR, no se puede convertir a alguno de los demás tipos de datos.

Para ello, usamos la función CAST()

Ejemplo 1. Creando una tabla que tendrá una columna de tipo BOOLEAN

CREATE TABLE
   MiTabla (
      MiColumnaEntera   INTEGER,
      MiColumnaBoolean1 BOOLEAN
) ;

COMMIT;

Ejemplo 2. Insertando valores en una columna de tipo BOOLEAN

INSERT INTO
   MiTabla
      VALUES (1, TRUE);

INSERT INTO
   MiTabla
      VALUES (2, 5 IS DISTINCT FROM 4);

INSERT INTO
   MiTabla
      VALUES (3, NULL);

Ejemplo 3. Asignando valores a una columna de tipo BOOLEAN

UPDATE
   MiTabla
SET
   MiColumnaBoolean1=TRUE,
   MiColumnaBoolean2=FALSE,
   MiColumnaBoolean3=2=4,
   MiColumnaBoolean4=NULL,
   MiColumnaBoolean5=UNKNOWN,
   MiColumnaBoolean6=5 > 1
WHERE
   MiCondición

Ejemplo 4. Consultando los valores de una columna de tipo BOOLEAN

SELECT
   *
FROM
   MiTabla
WHERE
   MiColumnaBoolean1

Esta consulta nos mostrará todas las filas que tengan TRUE en la columna MiColumnaBoolean1.

Ejemplo 5. Consultando por FALSE

SELECT
   *
FROM
   MiTabla
WHERE
   MiColumnaBoolean1 IS FALSE

Ejemplo 6. Consultando por UNKNOWN

SELECT
   *
FROM
   MiTabla
WHERE
   MiColumnaBoolean1 IS UNKNOWN

SELECT
   *
FROM
   MiTabla
WHERE
   MiColumnaBoolean1 IS NULL

Conclusión:

Algo que siempre le había faltado a Firebird era tener un verdadero tipo de datos BOOLEAN, podíamos suplir esa carencia creando un dominio pero hacerlo así no era del todo completo. Ahora, con Firebird 3 sí ya tenemos un verdadero tipo de datos BOOLEAN.

Los resultados de una comparación pueden ser: “verdadero”, “falso”, “desconocido”. Y esos son justamente los valores que podemos guardar en una columna definida como de tipo BOOLEAN, aunque desde luego que usaremos las palabras reservadas: TRUE, FALSE, UNKNOWN.

Para las comparaciones podemos usar el operador IS [NOT] o los operadores de comparación matemáticos.

El resultado de un SELECT que contenga columnas de tipo BOOLEAN puede ser: <true>, <false>, <null>

Recuerda que NULL en SQL significa “desconocido”, y la palabra UNKNOWN también significa “desconocido”, por eso pueden usarse como sinónimos.

Artículos relacionados:

¿Por qué Firebird 3?

Los archivos de configuración del Firebird 3

Entendiendo a los plug-in del Firebird 3

Parametrizando el archivo DATABASES.CONF

Agregando el usuario SYSDBA en Firebird 3

El índice del blog Firebird21

El foro del blog Firebird21

Anuncios

Agregando el usuario SYSDBA en Firebird 3

8 comentarios

En las versiones anteriores de Firebird, ya por defecto en el archivo de seguridad (SECURITY.FDB en 1.x y SECURITY2.FDB en 2.x) existía un usuario llamado SYSDBA y con la contraseña masterkey.

Bien, ese ya no es el caso con Firebird 3, ahora ningún usuario predeterminado existe, ni siquiera SYSDBA. Por lo tanto, nosotros debemos crearlos.

Siempre el usuario SYSDBA tendrá acceso al 100% de las bases de datos, pero como no existe un usuario SYSDBA nosotros lo crearemos. ¿Cuál es la ventaja de esto? Que SYSDBA ya no tendrá por defecto la contraseña masterkey sino la contraseña que a nosotros se nos ocurra asignarle.

Con las versiones 1.x y 2.x si un intruso quería conocer el contenido de una Base de Datos lo tenía muy fácil:

  1. Copiaba o hacía un backup de la Base de Datos
  2. Copiaba o restauraba esa Base de Datos en otra computadora, en una donde conociera la contraseña del usuario SYSDBA.
  3. Listo

Ahora, con Firebird 3 algo así ya no le será posible. ¿Por qué no? Porque si copia o restaura la Base de Datos en otra computadora tendrá un gran problema ¿cuál es la contraseña del usuario SYSDBA que se necesita para conectarse a la Base de Datos? Desde luego que no será masterkey (salvo que el Administrador sea un verdadero bobo) y si no conoce esa contraseña no conseguirá el acceso. Claro, puede copiar también el archivo de seguridad (SECURITY3.FDB por defecto) pero estará en la misma: si no conoce la contraseña no conseguirá la conexión. Y además, en un entorno donde la seguridad sea muy importante el archivo de seguridad no será SECURITY3.FDB sino otro archivo con totalmente otra estructura y ubicado donde se haya especificado en DATABASES.CONF (quizás en otra carpeta de otro disco duro de otra computadora).

En síntesis, la tarea del intruso ahora será mucho más dificultosa. No imposible, porque en Informática la seguridad al 100% es imposible de conseguir, pero sí muchísimo más dificultosa que en las versiones anteriores del Firebird.

¿Cómo agrego al usuario SYSDBA?

Recuerda que al instalar Firebird 3 ningún usuario existe, ni siquiera SYSDBA, entonces ¿cómo hacemos para agregar al usuario SYSDBA y con la contraseña que se nos ocurra asignarle?

Mediante el siguiente comando:


GSEC -add SYSDBA -pw Secreto -user SYSDBA

El programa GSEC.EXE lo encontrarás en la misma carpeta donde instalaste el Firebird 3.

Y la contraseña que elijas no será Secreto, ese es solamente un ejemplo.

Conclusión:

Para hacerle la vida muchísimo más difícil a los intrusos ahora en Firebird 3 el usuario SYSDBA no existe por defecto sino que debemos crearlo nosotros. Así mismo tampoco tiene una contraseña por defecto, su contraseña inicial será la que le asignemos al crearlo, la muy famosa masterkey ya no existe (salvo que alguien sea muy bobo como para asignársela al usuario SYSDBA).

Para agregar al usuario SYSDBA y asignarle su contraseña inicial (la cual no debería ser masterkey) usamos el programa GSEC.EXE que se encuentra en la misma carpeta donde instalamos al Firebird 3.

Artículos relacionados:

¿Por qué Firebird 3?

Los archivos de configuración del Firebird 3

Entendiendo a los plug-in del Firebird 3

Parametrizando el archivo DATABASES.CONF

El índice del blog Firebird21

El foro del blog Firebird21

Parametrizando el archivo DATABASES.CONF

1 comentario

Como ya hemos visto en artículos anteriores, el archivo DATABASES.CONF es el antiguo archivo ALIASES.CONF que ahora en Firebird 3 tiene un nuevo nombre y nuevas funcionalidades.

En ALIASES.CONF lo que hacíamos era darle un alias, apodo, nombre abreviado, o sobrenombre a las bases de datos. Hacíamos esto por dos motivos principalmente:

  1. Para usar el nombre abreviado cuando queríamos conectarnos a una Base de Datos, pues era más corto y más fácil de recordar
  2. Para dificultar el trabajo de algún intruso, pues conocer el alias no le permitía conocer la ubicación de la Base de Datos

Ejemplo de contenido del archivo ALIASES.CONF


ADMIN=D:\DATABASES\ADMINISTRATIVO.FDB

CONTA=E:\SISTEMAS\CONTABILIDAD\DATABASES\CONTA.FDB

En DATABASES.CONF podemos hacer eso mismo pero además podemos determinar el comportamiento de cada Base de Datos, de forma individual. Si lo deseas puedes renombrar a un antiguo archivo ALIASES.CONF como DATABASES.CONF y funcionará perfectamente. Pero además puedes parametrizarlo.

Los parámetros que especificamos en DATABASES.CONF pueden afectar al Servidor o al Cliente.

Parámetros de DATABASES.CONF que afectan al Servidor

  • DatabaseGrowthIncrement
  • DeadlockTimeout
  • DefaultDbCachePages
  • EventMemSize
  • FileSystemCacheThreshold
  • ExternalFileAccess
  • GCPolicy
  • LockAcquireSpins
  • LockHashSlots
  • LockMemSize
  • MaxUnflushedWrites
  • MaxUnflushedWriteTime
  • SecurityDatabase
  • SharedCache
  • SharedDatabase
  • UserManager
  • WireCrypt
  • WireCryptPlugin

Parámetros de DATABASES.CONF que afectan al Cliente

  • AuthClient
  • Providers

¿Cómo se especifican los parámetros?

A continuación del alias otorgado a una Base de Datos abrimos llave, parametrizamos, cerramos llave. Al igual que en FIREBIRD.CONF podemos comentar una línea (o parte de una línea) si escribimos en ella el símbolo de numeral (#)

Ejemplo de contenido del archivo DATABASES.CONF


# Esta es la Base de Datos que uso para registrar los datos de uso administrativo

ADMIN=D:\DATABASES\ADMINISTRATIVO.FDB

{

LockMemSize=32M     # Esta Base de Datos necesita muchísimos bloqueos

LockHashSlots=19927     # y una "hash table" suficientemente grande para ellos

}

# Esta es la Base de Datos que uso para la Contabilidad

CONTA=E:\SISTEMAS\CONTABILIDAD\DATABASES\CONTA.FDB

{

# Aquí se guardarán los nombres de los usuarios y sus contraseñas

SecurityDatabase=E:\SISTEMAS\CONTABILIDAD\DATABASES\SEGURIDAD.FDB

}

Como puedes ver, es muy sencillo. Para que el Firebird 3 sepa cual Base de Datos estás parametrizando a continuación de su alias abres llave, parametrizas, cierras llave. Y si quieres, puedes escribir comentarios, todo lo que escribas a continuación de un símbolo de numeral (#) será tratado como un comentario.

Usando macro substitución

Lo anteriormente visto es interesante, pero no es todo, aún hay más. Y es que ahora también podemos usar macro substitución en los archivos de configuración.

¿Qué es macro substitución?

Es usar unos caracteres predeterminados para referirse a algo. Es muy similar a las variables que se usan en los lenguajes de programación. La sintaxis es la siguiente:

$(nombre_de_macro)

Las macro que pueden usarse en los archivos de configuración de Firebird3

  • $(root). El directorio raíz del Firebird
  • $(install). El directorio donde Firebird está instalado. Al inicio $(root) y $(install) son los mismos, son idénticos, pero $(root) puede ser cambiado con la variable de entorno FIREBIRD, en cuyo caso será diferente de $(install)
  • $(this). El directorio donde el actual archivo de configuración está ubicado
  • $(dir_conf). El directorio donde FIREBIRD.CONF y DATABASES.CONF están ubicados
  • $(dir_secdb). El directorio donde la Base de Datos de seguridad que se usa por defecto está ubicada
  • $(dir_plugins). El directorio donde se encuentran los plug-in
  • $(dir_udf). El directorio donde se encuentran por defecto las UDF (User Defined Functions=funciones definidas por el usuario)
  • $(dir_sample). El directorio donde se encuentran los ejemplos
  • $(dir_sampleDb). El directorio donde la Base de Datos de ejemplo (EMPLOYEE.FDB) se encuentra ubicada
  • $(dir_intl). El directorio donde los módulos internacionales se encuentran ubicados
  • $(dir_msg). El directorio donde el archivo de mensajes (FIREBIRD.MSG) se encuentra ubicado. Al inicio, $(dir_msg) es idéntido a $(root) pero puede cambiarse con la variable de entorno FIREBIRD_MSG

Ejemplo del uso de macro substitución


# La Base de Datos que el Firebird trae como ejemplo

EJEMPLO=$(dir_sampleDb)\employee.fdb

{

# La Base de Datos donde se encuentran los nombres de los usuarios y sus contraseñas

SecurityDatabase=$(root)\SEGURIDAD\SEGURIDAD.FDB

}

Aquí lo que dijimos es que al conectarse a la Base de Datos cuyo alias es EJEMPLO se conecte en realidad a la Base de Datos cuyo nombre es EMPLOYEE.FDB y usando los nombres de usuarios y contraseñas que se encuentran en la Base de Datos de nombre SEGURIDAD.FDB

Conclusión:

El antiguo archivo ALIASES.CONF era muy útil para escribir menos y para dificultarles las tareas a los intrusos, el moderno archivo DATABASES.CONF además de eso también nos permite parametrizar a cada Base de Datos de forma individual, para ello a continuación del alias abrimos llave, parametrizamos, y cerramos llave. Una ayuda en nuestra tarea es la macro substitución la cual también nos permite escribir menos y además no necesitamos recordar la ubicación física de los archivos porque la macro se encarga de eso.

Artículos relacionados:

¿Por qué Firebird 3?

Los archivos de configuración del Firebird 3

Entendiendo a los plug-in del Firebird 3

El índice del blog Firebird21

El foro del blog Firebird21

Entendiendo a los plug-in del Firebird 3

Deja un comentario

Los plug-in normalmente traducidos al castellano como “complementos” aunque más propiamente sería “enchufables” son pequeñas rutinas que permiten cambiar la funcionalidad o la apariencia de un programa.

En otras palabras, los plug-in permiten agregarle o cambiarle algo al programa principal (en inglés: host).

Y la gran ventaja de que un programa permita plug-in es que cualquier programador puede agregarle o cambiarle algo al programa principal, no solamente los programadores del programa principal pueden hacerlo.

¿Cómo funcionan los plug-in?

El programa principal (host) tiene un método que permite que los plug-in se registren a sí mismos y también un protocolo para el intercambio de datos.

Si hay un plug-in registrado entonces el programa principal (host) bifurca su ejecución al plug-in, en otras palabras no ejecuta su propia rutina sino que ejecuta la rutina del plug-in.

Cuando el plug-in finaliza, devuelve el control al programa principal (host)

plug-in

Gráfico 1. Si haces clic en la imagen la verás más grande

Como puedes ver en el Gráfico 1, la Rutina 2 no se ejecuta si hay un plug-in. La Rutina 2 es ignorada y en su lugar se ejecuta el plug-in.

¿Por qué usar plug-in?

Porque de esta manera muchos programadores externos pueden aportar nuevas características o funcionalidades, o mejorar las actuales.

Usando plug-in en Firebird 3

Dos puntos débiles del Firebird siempre fueron:

  1. La seguridad de sus bases de datos
  2. Que los datos no se transmitían encriptados en la red

Del punto 1. hablaremos en otros artículos.

El punto 2. se ha solucionado mediante el uso de plug-in, ya que ahora tenemos la posibilidad de usar nuestras propias rutinas de encriptación. ¿Qué significa eso? Que aunque un atacante intercepte la transmisión en la red no le servirá porque no podrá entender qué significan los datos transmitidos. Para entenderlos necesitará sí o sí del plug-in que nosotros creamos, y si lo mantenemos en secreto entonces …. aunque intercepte los datos transmitidos, no podrá entenderlos.

Cualquier programador suficientemente avanzado puede crear un plug-in.

¿En cuáles lenguajes de programación se puede crear un plug-in para Firebird 3?

Recuerda que un plug-in es una rutina externa creada por cualquier persona, y por lo tanto el programa principal (host) debe poder entenderlo. Y para que pueda entenderlo ambos deben usar el mismo protocolo. Este protocolo se implementa por medio de librerías de enlace dinámico.

Las librerías de enlace dinámico tienen la extensión .dll en Windows y .so en Linux, y pueden ser de dos tipos:

  1. DECLARE DLL
  2. COM DLL

Los plug-in se implementan a través de DECLARE DLL, por lo tanto cualquier lenguaje de programación que las pueda crear podrá ser utilizado. Ejemplos: C, C++, Delphi, Lazarus, etc. Hay lenguajes que pueden usar las DECLARE DLL pero no pueden crearlas y por lo tanto no podrás crear un plug-in con ellos. Ejemplo: Visual FoxPro.

Conclusión:

Los plug-in son rutinas externas creadas para aumentar la funcionalidad del programa principal o host. Cualquier programador avanzado puede crear un plug-in. Ahora, con Firebird 3 tenemos la posibilidad de crear nuestros propios plug-in y así aumentar la seguridad.

Nota:

El autor de este blog creará un plug-in y mostrará su código fuente y la interfaz para que se pueda comprender como crearlos y hacerlos funcionar.

Artículos relacionados:

Los archivos de configuración del Firebird 3

El índice del blog Firebird21

El foro del blog Firebird21

Los archivos de configuración del Firebird 3

3 comentarios

En Firebird 3 hay dos archivos de configuración:

  • FIREBIRD.CONF
  • DATABASES.CONF

El archivo FIREBIRD.CONF ya existía en las versiones anteriores del Firebird, ahora solamente se le han agregado nuevas entradas. Aquí determinamos los parámetros de configuración que usarán todas las bases de datos (salvo que se los modifique en DATABASES.CONF).

El archivo DATABASES.CONF es nuevo en Firebird 3, aunque en realidad es el antiguo ALIASES.CONF con un nuevo nombre y más funcionalidades. Aquí determinamos los parámetros de configuración que usará cada una de las Bases de Datos.

Los nuevos parámetros de FIREBIRD.CONF

SecurityDatabase. En las versiones anteriores de Firebird los nombres y las contraseñas de los usuarios se guardaban en los archivos SECURITY.FDB (para 1.x) o en SECURITY2.FDB (para 2.x). El gran problema era que muy fácilmente se podía quebrar la seguridad: el intruso simplemente copiaba la Base de Datos en otra computadora donde conociera la contraseña del usuario SYSDBA y listo. Ahora, tal cosa ya no le será posible. Con esta versión el archivo se llama SECURITY3.FDB por defecto, pero puede usarse otro archivo y además también puede tenerse un archivo de seguridad específico para cada Base de Datos (en este caso, se lo especifica en DATABASES.CONF)

AuthServer y AuthClient. Estos parámetros determinan cuales son los métodos de autenticación que serán usados por el Servidor y el Cliente.

WireCrypt. Establece si la conexión será encriptada o no. Si la conexión está encriptada entonces aunque un intruso capture los datos transmitidos no podrá saber el significado de ellos.

UserManager. Establece el plug-in que operará en la Base de Datos de seguridad (por defecto: SECURITY3.FDB), este valor puede cambiarse para cada Base de Datos en el archivo DATABASES.CONF

TracePlugin. Especifica el plug-in que usará el programa Trace para enviar datos de rastreo a la aplicación cliente o para auditar datos en el archivo de log.

WireCryptPlugin. Especifica el plug-in usado para encriptar y desencriptar los datos que son transferidos en la red.

KeyHolderPlugin. Este parámetro representaría alguna forma de almacenamiento temporario para las claves de encriptación de las bases de datos. Actualmente, no tiene un valor por defecto.

Providers. Son los métodos usados para conectar a un Cliente con un Servidor. Mediante ellos se puede: a) conectarse remotamente o localmente a bases de datos creadas con Firebird 3, b) conectarse a base de datos creadas con versiones anteriores de Firebird, c) conectarse a bases de datos creadas por otros motores (Oracle, Postgre, MySQL, etc.)

SharedCache. Junto con SharedDatabase determinan el modo de ejecución del Servidor (Classic, SuperClassic, SuperServer, Embedded).

SharedDatabase. Junto con SharedCache determinan el modo de ejecución del Servidor (Classic, SuperClassic, SuperServer, Embedded).

RemoteAccess. Provee un eficiente y configurable método para limitar el acceso al archivo de seguridad SECURITY3.FDB, a sus reemplazantes y a cualquier otra Base de Datos.

IPv6V6Only. Determina si la conexión puede establecerse solamente mediante IPv6 o si podrá usarse tanto IPv4 como IPv6.

Los parámetros cambiados de FIREBIRD.CONF

ExternalFileAccess. Si a una entrada en la lista de Restrict le falta una carpeta, se crea la carpeta faltante.

Los parámetros eliminados de FIREBIRD.CONF

RootDirectory.

LegacyHash.

OldSetClauseSemantics.

OldColumnNaming.

LockGrantOrder.

UsePriorityScheduler.

PrioritySwitchDelay.

PriorityBoost.

Los nuevos parámetros de DATABASES.CONF

El archivo DATABASES.CONF en realidad es el antiguo archivo ALIASES.CONF pero bastante mejorado. Con ALIASES.CONF podíamos tener alias o sobrenombres para nuestras bases de datos. Ahora además de eso también podemos establecer parámetros que son específicos a cada una de las bases de datos.

SecurityDatabase. Define el nombre y la ubicación del archivo que guarda los nombres y las contraseñas de los usuarios. Por defecto es el archivo SECURITY3.FDB que se encuentra en la carpeta raíz del Firebird 3, pero puede usarse cualquier otro archivo que se encuentre en cualquier otra ubicación.

AuthServer y AuthClient. Determinan los métodos de autenticación que serán usados por el Servidor y el Cliente, respectivamente.

WireCrypt. Establece si la conexión será encriptada.

UserManager. Establece el plug-in que será usado en la Base de Datos de seguridad.

TracePlugin. Establece el plug-in que será usado por el programa Trace que envía datos de rastreo a la aplicación cliente o que audita los datos en un archivo de log.

WireCryptPlugin. Es un plug-in usado para encriptar y desencriptar los datos transferidos en la red.

KeyHolderPlugin. Este parámetro representaría alguna forma de almacenamiento temporario para las claves de encriptación de las bases de datos. Actualmente, no tiene un valor por defecto.

Providers. Son los métodos usados para conectar a un Cliente con un Servidor. Mediante ellos se puede: a) conectarse remotamente o localmente a bases de datos creadas con Firebird 3, b) conectarse a base de datos creadas con versiones anteriores de Firebird, c) conectarse a bases de datos creadas por otros motores (Oracle, Postgre, MySQL, etc.)

SharedCache. Junto con SharedDatabase determinan el modo de ejecución del Servidor (Classic, SuperClassic, SuperServer, Embedded).

SharedDatabase. Junto con SharedCache determinan el modo de ejecución del Servidor (Classic, SuperClassic, SuperServer, Embedded).

RemoteAccess. Provee un eficiente y configurable método para limitar el acceso al archivo de seguridad SECURITY3.FDB, a sus reemplazantes y a cualquier otra Base de Datos.

IPv6V6Only. Determina si la conexión puede establecerse solamente mediante IPv6 o si podrá usarse tanto IPv4 como IPv6.

Conclusión:

Ahora, con Firebird 3 tenemos un archivo FIREBIRD.CONF cambiado, al cual se le han agregado varias entradas, principalmente en el área de seguridad.

También disponemos de un archivo llamado DATABASES.CONF que es el antiguo ALIASES.CONF con el nombre cambiado y con muchas más opciones, las cuales nos permiten establecer exactamente los parámetros que afectarán a cada Base de Datos.

Las mejoras en la seguridad son muy significativas, ahora a un posible atacante le será mucho más difícil interceptar o entender los datos que son transferidos por la red.

En sucesivos artículos de este blog iremos viendo con mayor detenimiento cada uno de los parámetros de los archivos FIREBIRD.CONF y DATABASES.CONF, para entenderlos mejor y así poder obtener el máximo provecho de ellos.

Artículos relacionados:

Alias, archivos y rutas

Configurando al Firebird

Programa para configurar el Firebird

Aumentando la seguridad con ALIASES.CONF

El índice del blog Firebird21

El foro del blog Firebird21

¿Por qué Firebird 3?

1 comentario

Como seguramente sabes, no existe software perfecto, todos pueden ser mejorados en mayor o menor medida y es por ese motivo que van saliendo nuevas versiones.

Lo mismo sucede con Firebird, que va adquiriendo nuevas características que lo hacen más poderoso, más confiable y más rápido.

La versión 3.0 tiene como principales objetivos:

  • Unificar la arquitectura del Servidor
  • Mejorar el soporte para SMP (Symetric Multi-Processing)
  • Aumentar el rendimiento en computadoras multi-núcleo

Pero además se quiso mejorar varios puntos, como el de la seguridad de las bases de datos, que era un pedido de muchísima gente y durante muchísimo tiempo. Ahora sí, las bases de datos de Firebird pueden ser muy seguras.

Actualmente Firebird (versión 2.5.4) tiene cuatro arquitecturas diferentes:

  • Classic
  • SuperClassic
  • SuperServer
  • Embedded

Cada una de ellas tiene sus fortalezas y sus debilidades. Las necesidades de las organizaciones y de las personas son diferentes y por eso existen cuatro arquitecturas. En Firebird 3.0 el archivo ejecutable es uno solo y se le indica cual de las arquitecturas se desea cambiando dos parámetros en un archivo de configuración.

En Firebird 3.0 el modo SuperServer ya usa múltiples CPUs y núcleos.

Y mejorando los threadings (hilos), la compartición del caché y el uso de los procesadores se aumentó el desempeño en computadoras con múltiples procesadores.

Conclusión:

Firebird 3.0 viene con muchas mejoras muy significativas. Por un lado, se obtiene mayor aprovechamiento del hardware, por otro lado la seguridad de las bases de datos se ha incrementando muchísimo, y por otro lado se ha mejorado el SQL que utiliza.

Todo eso nos da (gratuitamente, no lo olvides) un motor de excelentes prestaciones, apto tanto para aplicaciones pequeñas como para las aplicaciones más grandes que te puedas imaginar.

Muy rápido, muy fácil de configurar, muy poderoso, muy seguro. Y totalmente gratis. Todo eso lo hace a Firebird 3.0  palabra mayor en cuanto a motores SQL.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

Nueva categoría del blog: Firebird 3

2 comentarios

Con la liberación de la Beta 2 de Firebird 3.0 el momento de contar con la nueva (y tan esperada) versión está cada vez más cercano. Como las novedades y los cambios y las mejoras son tantos, este blog desde ahora cuenta con una nueva categoría, llamada Firebird 3.

Como lo puedes suponer, en esta nueva categoría se colocarán todos los artículos directamente relacionados con Firebird 3 para que antes de su liberación definitiva ya puedes ir teniendo un adelanto de lo que se viene.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

Newer Entries