Usando un PLAN

16 comentarios

Cuando va a ejecutar un SELECT el Firebird automáticamente busca el mejor plan para que esa consulta sea lo más rápida posible. El Firebird posee lo que se denomina un “optimizador de consultas”. La tarea de dicho optimizador es conseguir la consulta más rápida de todas.

¿Qué es un plan?

Es la lista de todos los índices u ordenamientos que usará una consulta. También puede darse el caso de que lo mejor sea no usar índices ni ordenar la consulta.

¿El Firebird siempre usa un plan?

Sí, siempre. Sea cual sea el SELECT que escribamos siempre tendrá un plan: el que le asignó automáticamente el Firebird o el que le especificamos manualmente nosotros.

¿Cómo se especifica un plan?

Dentro del comando SELECT existe una clásula llamada PLAN y es allí donde escribimos el plan que queremos usar

¿Por qué no usar siempre el plan que automáticamente asigna el Firebird?

Porque aunque en la gran mayoría de los casos esa es la mejor alternativa hay veces en que la elección del Firebird no es la más adecuada. Si sabemos los que es un plan y como funciona podemos darnos cuenta de que se podría mejorar el rendimiento usando un plan distinto. Afortunadamente podemos hacer eso.

¿En qué casos el Firebird puede elegir un mal plan?

En general cuando las estadísticas están desactualizadas y tenemos algún índice con baja selectividad (es decir: pocos valores distintos). El optimizador usa la selectividad en su algoritmo para decidir si debe usar un índice o no. Si la selectividad está desactualizada y no representa fielmente al índice entonces el optimizador puede usar un índice que no debería de usar o dejar de usar un índice que sí debería usar.

 Esta es la principal razón por la cual siempre debemos tener las estadísticas de nuestros índices actualizadas: para que el optimizador del Firebird utilice correctamente a los índices en cada SELECT.

¿Cómo le indico que debe recalcular la estadística de un índice para hallar su selectividad actual?

Con el comando:

SET STATISTICS NombreIndice;

¿Por qué debo pedirle que reconstruya las estadísticas?

Porque el Firebird solamente calcula las estadísticas cuando un índice es creado y después de un ciclo backup/restore. Eso implica que si no le pides que las reconstruya pueden estar desactualizadas.

¿Y cómo reconstruyo un índice?

Escribiendo:

ALTER INDEX NombreIndice INACTIVE;

ALTER INDEX NombreIndice ACTIVE;

¿Y por qué debo pedirle que reconstruya un índice?

Porque después de realizar muchas inserciones, borrados, o modificaciones que afectan a un índice el índice suele quedar desbalanceado y tú deberías asegurarte que está bien balanceado. Un índice desbalanceado es recorrido más lentamente. Escribiendo los comandos de arriba conseguirás balancearlo y por lo tanto mejorar la velocidad de consulta.

¿Cómo puedo saber cuál plan está usando el Firebird en cada consulta?

En ISQL, escribes:

SET PLAN;

Y luego, cada vez que escribas el comando SELECT lo primero que verás será el plan utilizado

PLAN4

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

En EMS SQL Manager, haces click en: Show SQL Editor (o presionas la tecla F12); o también puedes hacer click en: New SQL Editor (o presionas las teclas Shift + F12)

PLAN1

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

Verás una ventana donde podrás escribir tus comandos, luego de escribir tu SELECT en esa ventana haces click donde dice “Explain query” (explicar la consulta, en castellano)

PLAN2

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

Y en la parte inferior verás algo similar a esto:

PLAN3

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

¿Qúe significa la palabra “NATURAL” en un plan?

Que no se está usando ningún índice

¿Por qué a veces me dice que no se puede utilizar el plan especificado?

Porque en tu cláusula WHERE o en tu cláusula ORDER BY no estás teniendo todas las columnas que se usan en el índice

Ejemplo 1:

En la tabla CLIENTES tenemos una Primary Key compuesta por dos columnas: CLI_CODSUC (significa: código de la sucursal) y CLI_IDENTI (significa: identificador del cliente)

SELECT
   *
FROM
   CLIENTES
WHERE
   CLI_IDENTI > 0
PLAN
   (CLIENTES INDEX (PK_CLIENTES))

Al intentar ejecutar ese SELECT muestra el mensaje: “Index PK_CLIENTES cannot be used in the specified plan.” ¿Por qué muestra ese mensaje? Porque el índice PK_CLIENTES es un índice compuesto por dos columnas: CLI_CODSUC y CLI_IDENTI y arriba usamos la segunda columna solamente, al cambiar el SELECT anterior por este:

Ejemplo 2:

SELECT
   *
FROM
   CLIENTES
WHERE
   CLI_CODSUC = 0 AND
   CLI_IDENTI > 0
PLAN
   (CLIENTES INDEX (PK_CLIENTES))

todo funciona perfectamente porque en el WHERE se escribieron las dos columnas que componen al índice PK_CLIENTES. El Ejemplo 1. también habría funcionado perfectamente si en lugar de escribir: CLI_IDENTI > 0 hubiéramos escrito CLI_CODSUC = 0 ó también CLI_CODSUC > 0 ó cualquier otra combinación que involucre a la primera columna del índice.

¿Un plan puede involucrar a varias tablas?

Sí, por cada tabla que haya en tu SELECT en el plan se especificará cual índice se usará.

Ejemplo 3:

PLAN JOIN (V_ABM_VENTAS_CONTA V NATURAL,
           V_ABM_VENTAS_CONTA C INDEX (PK_CLIENTES),
           V_ABM_VENTAS_CONTA S INDEX (UQ_SUCURSALES))

En este caso vemos que la vista V_ABM_VENTAS_CONTA tiene:

  • Un orden NATURAL (o sea que no se usará ningún ordenamiento específico)
  • Un orden PK_CLIENTES (o sea que se usará la Primary Key de la tabla CLIENTES)
  • Un orden UQ_SUCURSALES (o sea que se usará la Unique Key de la tabla SUCURSALES)

Como las tres tablas de esa vista tienen alias, en lugar de ver los nombres de las tablas verás sus alias (en este caso V para la tabla principal (VENTAS), C para una de las tablas usadas en el JOIN (que se llama CLIENTES) y S para la otra tabla usada en el JOIN (que se llama SUCURSALES)

¿Puedo tener un ORDER en un plan si no tengo la cláusula ORDER BY en el SELECT?

No, porque eso no tiene sentido; el plan solamente usa las columnas que se especifican en el SELECT.

Ejemplo 4:

La tabla ASIENTOSCAB tiene un índice llamado ASC01. Ese índice está compuesto por las columnas: ASC_ANOEJE, ASC_CODSUC, ASC_NUMERO (año del ejercicio contable, código de la sucursal, número del asiento)

Este SELECT nos mostrará el error de que el índice no puede ser usado en el plan especificado:

SELECT
   *
FROM
   ASIENTOSCAB
PLAN
   (ASIENTOSCAB INDEX (ASC01))

¿Por qué el error? porque el SELECT no tiene una cláusula WHERE ni una cláusula ORDER BY. En cambio este SELECT sí funcionará:

SELECT
   *
FROM
   ASIENTOSCAB
WHERE
   ASC_ANOEJE = 2013
PLAN
   (ASIENTOSCAB INDEX (ASC01))

El SELECT de arriba funciona porque en la cláusula WHERE se especificó la primera columna del índice ASC01. El SELECT de abajo también funcionará:

SELECT
   *
FROM
   ASIENTOSCAB
PLAN
   (ASIENTOSCAB INDEX (ASC01))
ORDER BY
   ASC_ANOEJE

Este SELECT funciona porque en la cláusula ORDER BY se especificó la primera columna del índice ASC01.

¿Cuándo se debería especificar un PLAN manualmente?

Cuando la consulta es lenta. Cualquier consulta que tarde más de 5 segundos en mostrar sus resultados amerita que se averigüe el motivo y uno de esos motivos puede ser que está usando un mal plan.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

 

Anuncios

Trazabilidad en el tiempo

1 comentario

Cuando diseñas una Base de Datos generalmente tienes muchas formas de hacerlo, dicen que si a 100 personas les pides que diseñen una Base de Datos te encontrarás con más de 100 resultados (porque algunos te entregarán más de una).

Sin embargo, hay algunos consejos que pueden ser relevantes. Más allá de lo que seguramente ya conoces (normalización de las tablas, claves primarias subrogadas, índices en las columnas que se consultan frecuentemente, triggers en todas las tablas para evitar datos incorrectos, etc.) hay un punto que no todos conocen o toman en cuenta y que puede ser de vital importancia: trazabilidad en el tiempo.

¿Qué significa trazabilidad en el tiempo?

Que puedas retrotraer, que puedas regresar, tu Base de Datos a cualquier instante anterior.

¿Y para qué necesitaría retrotraer la Base de Datos a un instante anterior?

Para saber exactamente lo que tenías registrado en un determinado momento. Eso te permitirá responder preguntas tales como:

    • ¿Cuál era la cantidad en stock del producto XYZ el día 22 de abril de 2013 a las 09:15?
    • ¿Cuál era el saldo en cuenta corriente el día 23 de abril de 2013 a las 07:00?
    • ¿Cuánto se había vendido en la sucursal de Londres el día 24 de abril de 2013 a las 11:00 horas de acá?
    • ¿Cuáles fueron los cambios de precios de venta del producto XYZ el año pasado?
    • ¿Cuál era el precio de venta del producto XYZ antes de que el empleado Juan Pérez lo cambiara “por accidente”?
    • ¿Cuántos clientes tenía la sucursal de Nueva York el día 19 de abril de 2013, cuánto se les había vendido a esos clientes, cuánto se les había cobrado?

¿Cómo se consigue la trazabilidad en el tiempo?

  1. Nunca, jamás, una fila (registro) puede ser borrada. Lo que se hace es cambiar el valor de una columna de ACTIVO a INACTIVO
  2. Cada vez que: a) un fila es insertada o b) una fila es puesta en INACTIVO o c) una fila es modificada, se guardan en una tabla de log:
    • El identificador de la Sucursal
    • El nombre o identificador de la computadora
    • El nombre del usuario que insertó, inactivó o modificó
    • El nombre de la tabla
    • La fecha en la cual ocurrió la inserción, inactivación o modificación
    • La hora en la cual ocurrió la inserción, inactivación o modificación
    • El número de la transacción que insertó, inactivó o modificó
    • El valor anterior que tenía cada columna que fue modificada
  3. El punto 2. se realiza a través de un trigger AFTER INSERT OR UPDATE OR DELETE

¿Vale la pena que una Base de Datos tenga trazabilidad en el tiempo?

Sí, porque los usuarios muchas veces necesitan información de lo que ocurrió en el pasado, no solamente de lo que está ocurriendo ahora.

¿Cuál es la desventaja de tener una Base de Datos trazable en el tiempo?

Que puede llegar a ser muy grande, por eso suele ser recomendable que para ello utilices una Base de Datos auxiliar.

Partner index description is not found

1 comentario

Este problema ocurre cuando se definió una Primary Key o una Foreign Key y su índice no se encuentra, no existe. Y debería existir. Para descubrir cual es el índice faltante puedes escribir la siguiente consulta:

SELECT
   I.RDB$RELATION_NAME   AS "Nombre de la Tabla",
   R.RDB$CONSTRAINT_NAME AS "Nombre de la restricción",
   R.RDB$INDEX_NAME      AS "Nombre del índice",
   I.RDB$INDEX_NAME      AS "Nombre real",
   I.RDB$INDEX_INACTIVE  AS "Estado"
FROM
   RDB$INDICES I
RIGHT JOIN
   RDB$RELATION_CONSTRAINTS R
      ON I.RDB$INDEX_NAME = R.RDB$INDEX_NAME
WHERE
   R.RDB$CONSTRAINT_TYPE = 'PRIMARY KEY' OR
   R.RDB$CONSTRAINT_TYPE = 'FOREIGN KEY'
ORDER BY
   R.RDB$CONSTRAINT_NAME

El índice faltante es aquel que en la columna “Nombre real” está vacío. Para solucionar el problema debes recrear esa restricción.

En general este error ocurre cuando hay corrupción física en la Base de Datos. Sería una buena idea que hagas un backup, que restaures el backup, y que de ahí en adelante utilices la versión restaurada.

NOTA: En la columna “Estado” el valor 0 (cero) significa que el índice está ACTIVO, un valor de 1 significa que el índice está INACTIVO y un valor de NULL significa que es un nuevo índice.

 

Page 99999 is an orphan

1 comentario

Si encuentras este error (por ejemplo, en el archivo FIREBIRD.LOG que se encuentra en la carpeta donde instalaste el Firebird) el problema es el siguiente:

  • Un índice está corrupto

En general ocurre cuando hay intensivos insert/delete/update en una sola transacción.

Deshabilitar los índices antes de intensivos insert/delete/update es bueno por dos razones:

  1. Las operaciones de insert/delete/update serán mucho más rápidas
  2. No se corromperán los índices

Al finalizar las operaciones de insert/delete/update hay que volver a habilitar los índices.

Observación: el número 99999 del título representa a cualquier número entero. Por ejemplo en tu caso podrías encontrar el mensaje: “Page 124062 is an orphan”

Uso de la Primary Key

2 comentarios

Como sabes, una Primary Key es una clave que tiene estas dos características:

  • Sus valores son únicos (jamás se pueden repetir)
  • Sus valores no pueden ser NULL

Eso nos permite identificar a cada fila (a cada registro) de una forma unívoca, es decir con la total seguridad de que estamos identificando a la fila correcta.

¿Cuándo deberíamos utilizar una Primary Key?

1. Cuando deseamos consultar la tabla en el mismo orden en que las filas fueron cargadas

Por ejemplo, escribiendo:

SELECT
   PRD_IDENTI,     -- Identificador y Primary Key
   PRD_NOMBRE,     -- Nombre del producto
   PRD_PRECTO      -- Precio de costo del producto
FROM
   PRODUCTOS
ORDER BY
   PRD_IDENTI

2. Cuando hacemos búsquedas y queremos asegurarnos de obtener las filas correctas, sin la posibilidad de equivocarnos. Por ejemplo, supongamos que queremos borrar de la tabla de PRODUCTOS al producto cuyo identificador es 12345 y cuyo nombre es ‘Jugo de naranjas’. Si escribimos:

DELETE FROM
   PRODUCTOS
WHERE
   PRD_IDENTI = 12345

estaremos seguros de borrar a un solo producto, el que tiene como identificador al número 12345.

En cambio, si escribimos algo como:

DELETE FROM
   PRODUCTOS
WHERE
   PRD_PROCED = 'Japón'

Estaríamos borrando a todos los productos cuyo país de procedencia es Japón. Podríamos creer que hay un solo producto que tiene esa procedencia pero en realidad hay varios y en ese caso los estaríamos borrando a todos, lo cual sería un error grave.

Por ese motivo, en general, cuando de borrar se trata deberíamos usar la Primary Key, es más seguro.

Tablas agregadas

9 comentarios

Antes de continuar leyendo este artículo es altamente recomendable que leas:

https://firebird21.wordpress.com/2013/04/27/aplicaciones-oltp-y-aplicaciones-olap/

Si no leíste el artículo de arriba, el actual no tendrá tanto valor.

¿Qué es una tabla agregada?

Es una tabla que no guarda datos en bruto sino datos agrupados. Por ejemplo, en una tabla agregada no se guardan los datos de cada venta realizada sino los totales (diarios/semanales/mensuales/anuales) de esas ventas

¿Para qué se usan las tablas agregadas?

Para que los usuarios puedan obtener los resultados de sus consultas muy rápidamente

¿Cómo se insertan datos a las tablas agregadas?

A través de un programa que realiza un proceso de ETL (Extraction, Transformation, Loading, o en castellano: Extracción, Transformación, Carga)

Primero, se extraen los datos. Eso normalmente implica escribir un SELECT que contiene las funciones agrupadas: COUNT(), SUM(), AVG(), MAX(), MIN()

Segundo, se realizan algunas operaciones con esos datos (si es necesario, claro)

Tercero, se insertan dichos datos en la tabla agregada, la cual se encuentra en otra Base de Datos

¿Cuál es la principal tarea de una tabla agregada?

Guardar los resultados obtenidos al consultar otra/s tabla/s pero en muchísimas menos filas, por lo tanto las consultas a la tabla agregada serán mucho más rápidas que la respectiva consulta a la/s tabla/s original/es

¿Cómo se nombra a las tablas agregadas?

Aunque no es obligatorio hacerlo así, lo normal es que empiecen con el prefijo AGG_ para que todos los programadores puedan saber que se trata de una tabla agregada. Por ejemplo: AGG_VENTAS_MENSUALES, AGG_VENTAS_POR_VENDEDOR

 ¿Se deben usar tablas agregadas para todas las tablas de una Base de Datos OLTP?

No, solamente se justifica hacer el trabajo cuando las tablas OLTP tienen cientos de miles o millones de filas. Si las tablas OLTP tienen pocos miles de filas no se justifica el esfuerzo

¿Qué importante consideración debemos tener siempre en mente?

Que para que las tablas agregadas sean útiles deben tener sus filas actualizadas con los de la tabla (o tablas) OLTP correspondientes. Cada vez que los datos de una tabla OLTP son cambiados (porque se agregaron/borraron/modificaron filas) la tabla agregada relacionada con esa tabla OLTP esta automáticamente desactualizada. Esto implica que consultando a la tabla agregada se podría obtener un resultado diferente que consultando a la tabla OLTP. Y eso muchas veces no es admisible.

¿Cuáles son las estrategias para insertar, borrar o actualizar datos en una tabla agregada?

 En la literatura sobre OLAP y Data Warehousing se nombran tres estrategias:

    • Snapshot
    • Eager
    • Lazy

En snapshot (instantánea, en castellano) los datos de la tabla agregada son totalmente borrados y luego se les insertan los nuevos datos. O sea que cada vez se agregan los datos desde cero. Implementar esta estrategia es muy simple pero tiene un gran problema: la utilización del Servidor durante el tiempo que dura la inserción de las filas será muy intensiva haciendo que el tráfico en la red se vuelva muy lento para las demás aplicaciones. Por ese motivo se lo suele realizar en los horarios en que menos usuarios están conectados a las bases de datos.

En eager (ansioso, en castellano) hay un trigger para cada operación de insert/delete/update en la tabla OLTP. Cada vez que en la tabla OLTP se realiza un delete o un update dicho trigger debe recalcular los valores que pondrá en la tabla agregada. Esto significa que no se agregarán los datos desde cero como se hace en snapshot pero implementar esta estrategia es más complicado. La ventaja de usar esta estrategia es que la tabla agregada siempre está actualizada, la desventaja es que las operaciones en la tabla OLTP son más lentas porque cada insert/delete/update en ella debe actualizar a la tabla agregada también.

En lazy (perezozo, en castellano) hay un trigger en la tabla OLTP que guarda los cambios en otra tabla, en una tabla separada. Cada una de las filas de la tabla separada tiene una columna que nos indica si ya fue procesada o aún no. Periódicamente un stored procedure lee el contenido de la tabla separada y por cada fila que aún no fue procesada realiza el eager y marca a la fila como ya procesada. Esto implica que al igual que en la estrategia eager se necesita de operaciones de escritura pero la actualización se puede realizar en un mejor momento, normalmente cuando hay pocos usuarios conectados. Esta estrategia es una mezcla de las dos anteriores: no se satura al Servidor porque nunca se procesan todas las filas de la tabla OLTP y las filas de la tabla agregada están casi, casi, actualizadas con los de la tabla OLTP.

Conclusión:

Usar tablas agregadas es muy útil para aumentar la velocidad de respuesta a las consultas. En Firebird las podemos implementar utilizando stored procedures y triggers. También podemos utilizar cualquiera de las tres estrategias (snapshot, eager, lazy) mencionadas más arriba. Por supuesto que tendremos datos redundantes pero en general no deberíamos tener problemas por eso.

 

Aplicaciones OLTP y aplicaciones OLAP

12 comentarios

Las aplicaciones que normalmente desarrollamos son del tipo OLTP (On-Line Transaction Processing o en castellano: Procesamiento de Transacciones en Línea)

En este tipo de aplicaciones se insertan/borran/modifican datos en gran cantidad y más raramente se los consulta.

Como ejemplos tenemos: contabilidad, ventas, facturación, sueldos, producción

En todos esos casos lo normal es que se inserte una fila (un registro) por cada “movimiento” ocurrido. ¿Vendimos algo? insertamos una fila en la tabla de ventas. ¿Pagamos sueldo a un empleado? insertamos una fila en la tabla de pagos de sueldos.

Eso está muy bien y es lo correcto. Cuando alguien desea ver lo que se vendió o los sueldos que se pagaron con un SELECT se soluciona.

Sin embargo, empieza a complicarse cuando las consultas son muchas, ocurren muy frecuentemente y las filas que deben ser procesadas no se cuentan por miles sino por millones, por muchos millones.

Imagínate una empresa grande, con sucursales en varios países, que el año pasado ha realizado 500.000.000 de ventas o sea que  tiene 500.000.000 de facturas en un solo año.

Si nuestra aplicación es OLTP entonces cada vez que un usuario desea realizar una consulta a la tabla de ventas tendrán que procesarse 500.000.000 de filas, lo cual es una exageración y por supuesto que será muy lento. Dependiendo de la complejidad de lo que el usuario desee y de la velocidad de conexión, tal consulta podría insumir horas, lo cual es totalmente impracticable.

¿Cuál es la solución?

Construir aplicaciones OLAP.

¿Qué significa OLAP?

Son las siglas de On-Line Analytic Processing o en castellano: Procesamiento Analítico en Línea.

¿Para qué se usa OLAP?

Para consultar los datos que las aplicaciones OLTP guardaron en las bases de datos, las cuales se han vuelto inmensas porque algunas de sus tablas tienen muchos millones de filas.

¿Eso significa que hay relación entre las aplicaciones OLTP y las aplicaciones OLAP?

Sí, el paradigma funciona de la siguiente manera:

    • Una aplicación OLTP se encarga de insertar/borrar/modificar las filas que se guardarán en las tablas de una Base de Datos OLTP
    • Un programa agrupa esas filas y el resultado lo guarda en una Base de Datos OLAP
    • Cuando la consulta de un usuario envuelve a tablas pequeñas (de pocos miles de filas) se utiliza la Base de Datos OLTP, en cambio cuando envuelve a tablas que en la Base de Datos OLTP tienen millones de filas se usa la Base de Datos OLAP

¿Qué tienen de especial las tablas OLAP?

Que no guardan datos individuales sino datos agrupados. En nuestro ejemplo, la tabla de ventas en una Base de Datos OLTP tenía 500.000.000 de filas. Supongamos que un Gerente necesite consultar las ventas del año pasado, clasificadas por mes (o sea: cuanto se vendió en enero, cuanto se vendió en febrero, etc.)

Siendo así, podríamos tener una tabla llamada AGG_VENTAS con las siguientes columnas:

  • Año
  • Mes
  • Sucursal
  • CantidadFilas
  • SumaVentasDelMes
  • MaximaVenta
  • MinimaVenta

Supongamos ahora que esta empresa tiene 3.000 sucursales

Como habrá una fila por cada mes y por cada sucursal, tendremos 12 meses por 3.000 sucursales, lo cual nos da un total de 36.000 filas

Por lo tanto, todas las ventas del año pasado las tenemos registradas en solamente 36.000 filas y cualquier SELECT a esa tabla será muchísimo más rápido que un SELECT equivalente a la tabla de 500.000.000 de filas.

Recuerda que las filas de las tablas de una Base de Datos OLAP siempre tienen datos agrupados que provienen de las tablas de una Base de Datos OLTP.

Eso significa que no puedes construir una aplicación OLAP (que sí o sí debería usar una Base de Datos OLAP), si no tienes una Base de Datos OLTP.

¿Puedo construir aplicaciones OLAP con Firebird?

Sí, aunque nativamente el Firebird carece de las herramientas que otros SGBDR como Oracle o DB2 proveen, es perfectamente posible construir aplicaciones OLAP usando Firebird.

¿Qué estructuras usan las aplicaciones OLAP?

Para poder agilizar las consultas de grandes cantidades de datos se utilizan estructuras multidimensionales (las tablas de Firebird son bi-dimensionales) llamadas cubos OLAP que contienen los datos resumidos de grandes bases de datos OLTP.

¿Cuál es la principal razón de usar aplicaciones OLAP?

La gran velocidad de respuesta que se consigue.

¿Por qué se usan dos bases de datos, una para OLTP y otra para OLAP?

Aunque las tablas agrupadas podrían estar dentro de una Base de Datos OLTP eso no se hace así por las siguientes razones:

    1. La cantidad de conexiones concurrentes suele ser muy distinta. Mientras a una Base de Datos OLTP podrían estar conectados miles de usuarios a una Base de Datos OLAP generalmente no se conectan más que unas decenas de usuarios
    2. En las aplicaciones OLAP lo que se busca es conseguir la máxima velocidad, por lo tanto cuanto más pequeña sea la Base de Datos mucho mejor. Las bases de datos OLTP equivalentes son inmensas
    3. La configuración también es distinta porque quienes se conectan a bases de datos OLAP generalmente disponen de computadoras muy rápidas (no te olvides que suelen ser gerentes, presidentes, etc.) en cambio a las bases de datos OLTP podrían conectarse con computadoras lentas

¿Vale la pena construir aplicaciones OLAP?

Si quieres ganar mucho dinero la respuesta es un rotundo sí. Las aplicaciones OLAP se venden en muchos miles de dólares porque quienes compran esta clase de aplicaciones son empresas grandes.

¿Qué debe tener una aplicación OLAP?

Las aplicaciones OLAP se usan para ayudarles a los usuarios en la toma de decisiones. Por lo tanto es imprescindible que le provean de muchísimos gráficos. También la posibilidad de exportar sus datos a Excel, a PDF, a HTML y a cualquier otro formato que el usuario use en sus demás aplicaciones. Por supuesto muchas grillas y lo más importante: la facilidad de buscar y visualizar cualquier dato que precise, en cuestión de segundos.

Conclusión:

Las aplicaciones OLTP fueron construídas desde los inicios de la Informática y siempre existirán y siempre serán muy útiles pero las empresas grandes actualmente tienen tablas con muchos millones de filas y necesitan gran rapidez en las consultas, y esa rapidez no la pueden obtener con aplicaciones OLTP. La rapidez que necesitan solamente la pueden conseguir con aplicaciones OLAP. Como quienes compran estas aplicaciones son empresas grandes, pagan muy buen dinero por ellas.

Con Firebird se pueden desarrollar aplicaciones OLAP y en siguientes artículos veremos como.

 

Older Entries