Consultando sin importar mayúsculas ni acentos

1 comentario

A veces podríamos necesitar que la consulta nos traiga los datos sin importar que estén en mayúsculas, en minúsculas, acentuados o no acentuados. Por ejemplo queremos obtener: MARIA, MARÍA, maria, maría, Maria, María.

Para ello, debemos usar un ordenamiento (collation, en inglés) que termine con CI_AI ya que eso significa que al ordenar no diferencie entre mayúsculas y minúsculas ni entre vocales acentuadas y no acentuadas.

Al crear nuestra tabla, las columnas que deseamos que tengan esa característica deberían tener el atributo COLLATE ES_ES_CI_AI (si el character set de la Base de Datos es ISO8859_1) o UNICODE_CI_AI (si el character set es UTF8).

Ejemplo:

CREATE TABLE PERSONAS (
   PER_IDENTI INTEGER NOT NULL,
   PER_NOMBRE VARCHAR(40) COLLATE ES_ES_CI_AI,
   PER_APELLD VARCHAR(20) COLLATE ES_ES_CI_AI);

ALTER TABLE PERSONAS ADD CONSTRAINT PK_PERSONAS PRIMARY KEY (PER_IDENTI);

Si usamos el programa EMS SQL Manager para crear nuestras tablas entonces veríamos algo similar a esto:

INSENSITIVO3

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

Las columnas PER_NOMBRE y PER_APELLD de la tabla PERSONAS usan COLLATE ES_ES_CI_AI y por lo tanto al escribir esta consulta:

SELECT
   PER_NOMBRE,
   PER_APELLD
FROM
   PERSONAS
WHERE
   PER_NOMBRE LIKE 'MARIA%'

esto será lo que obtendremos:

INSENSITIVO1

Captura 2. Si haces clic en la imagen la verás más grande

o sea, todas las “María” que tenemos en nuestra tabla de PERSONAS, sin importar como se escribieron los nombres de esas personas. Claro que en el SELECT podríamos escribir UPPER(PER_NOMBRE) y UPPER(PER_APELLD) para que todos los nombres y apellidos estén en mayúsculas, y en ese caso obtendríamos:

INSENSITIVO2

Captura 3. Si haces clic en la imagen la verás más grande

lo cual, en general por una cuestión de estética, sería preferible. Fíjate que los nombres que se escribieron sin acentos siguen estando sin acentos, pero son mostrados, que es lo que queríamos conseguir. Si en nuestra tabla no hubiéramos usado COLLATE ES_ES_CI_AI entonces el SELECT no nos hubiera mostrado los nombres que tienen acento.

Artículo relacionado:

El índice del blog Firebird21

Forced writes

1 comentario

En cada una de nuestras bases de datos podemos determinar si los cambios que se realizan en ella se escribirán inmediatamente en el disco duro (FORCED WRITES = ON) o si se escribirán después de un tiempo (FORCED WRITES = OFF)

Si Forced Writes está en ON entonces tenemos dos ventajas:

  1. Los cambios se guardan en forma permanente. Un corte de la energía eléctrica no afectará a los datos ya guardados
  2. Los cambios se guardan siempre en el orden correcto. Por ejemplo, primero se guarda el registro y luego se guarda la entrada del índice que corresponde a ese registro

Si Forced Writes está en OFF tenemos una ventaja:

  1. Los datos se guardan mucho más rápidamente

Entonces ¿cuál es más conveniente?

En general, tener a Forced Writes en ON es lo mejor, esto es aún más notorio en Windows que en Linux. Porque cuando está en ON nos aseguramos que nunca haya pérdida de datos y que la Base de Datos siempre tenga consistencia. Si está en OFF, un corte de la energía eléctrica casi con seguridad hará que la Base de Datos se corrompa. Esa corrupción podría solucionarse, hay programas especializados en esa tarea, pero de todas maneras provocará molestias, inconvenientes y pérdida de tiempo y de dinero.

Podríamos tener Forced Writes en OFF solamente en casos especiales y muy puntuales, por ejemplo para insertar millones de filas desde una tabla externa. Una vez que esa inserción masiva ha finalizado volvemos a colocar Forced Writes en ON.

¿Cómo podemos saber si nuestra Base de Datos tiene Forced Writes en ON o en OFF?

Ejecutando el programa GSTAT.EXE que se encuentra en la carpeta \BIN de donde instalaste el Servidor del Firebird. A ese programa le pones como parámetros el nombre completo o el alias de la Base de Datos que deseas verificar y en la entrada Attributes te mostrará el estado actual de Forced Writes.

FORCED1

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

Después de escribir GSTAT y el alias de una Base de Datos se puede ver el estado de Forced Writes, que en este caso está en ON. O sea, que es lo correcto durante el uso normal.

¿Cómo se puede cambiar el estado de Forced Writes?

Mediante el programa GFIX.EXE, el cual tiene una opción llamada -write que puede ser sync (para que Forced Writes esté en ON) o async (para que Forced Writes esté en OFF)

FORCED2

 

Captura 2. Si haces clic en la imagen la verás más grande

Como puedes ver, al usar la opción -writes async del programa GFIX.EXE (flecha 1) el estado de Forced Writes se cambió a OFF como nos muestra el programa GSTAT.EXE (flecha 2) porque a continuación de Attributes no hay algo escrito.

Conclusión:

En general, lo conveniente es que Forced Writes esté en ON porque eso nos asegura que todos los datos se guarden y que se guarden en el orden correcto. Un corte de la energía eléctrica no ocasionará pérdidas de datos. Poner a Forced Writes en OFF puede ser muy útil cuando debemos realizar una entrada masiva de datos, pero no debemos olvidarnos de volver a ponerlo en ON apenas esa entrada masiva de datos finalice.

Artículo relacionado:

El índice del blog Firebird21