Búsqueda y arrays, una forma de hacer multibúsquedas (I)

Hace poco, un amigo me planteó el siguiente problema  que se le daba en una aplicación.

En una empresa, hay una serie de departamentos. Dentro de cada departamento, hay niveles de acceso a la información de una tabla (NOTICIAS). Cada persona de la empresa tiene un determinado NIVEL  dentro de cada DEPARTAMENTO y una persona solo puede acceder a las informaciones de cada uno de sus departamentos y dentro de ellas a las que su nivel se lo permita. Por ejemplo, si hay 10 niveles y tengo asignado en el departamento de contabilidad el nivel 4, podré acceder a toda la información de contabilidad con nivel 4, 5, 6,7,8,9 ó 10.

El esquema de tablas que hice fue el siguiente:

Esquema

Esquema de tablas

La tabla CLASIFICACION  tiene como objetivo mantener un histórico de los DEPARTAMENTOS  y NIVELES que tiene en cada uno de ellos cada PERSONA de la empresa. Tiene solamente tres campos punteros a maestro PERSONAS, DEPARTAMENTOS y NIVELES  y un índice de clave única formado por los tres campos punteros.

La tabla NOTICIAS  ( puede también llamarse APUNTES o NOTIFICACIONES, como cada cual quiera ) tiene un campo CODIGO, NOMBRE y un puntero a DEPARTAMENTO y otro a NIVELES que le renombré como Nivel Mínimo. A su vez creé un índice formado por la terna DEPARTAMENTO-NIVEL .

Para que desde una ficha de modificación de persona, se muestren las NOTICIAS  que le corresponde, monté los siguientes objetos visuales:

  • variable global en memoria  DEPARTAMENTO
  • variable global en memoria NIVEL
  • variable global en memoria TOTAL NIVELES

Las tres numéricas

  • Una búsqueda en la tabla NOTICIAS: NOTICIAS-PERSONA, en la que se busca por dos índices, primero por el de departamento, parte izquierda, valor $DEPARTAMENTO$  al que se le cruza la búsqueda por el índice NIVEL, entre límites, limite inicial $NIVEL$ , límite final $TOTAL NIVELES$
Búsqueda

Búsqueda de noticias-personas

  • Un proceso con origen ficha de PERSONAS que alimenta la rejilla que se mostrará en el formulario de modificación de la persona,con  las noticias a las que tiene acceso.

Proceso

En este proceso son fundamentales tres cosas: la cesta y los dos arrays.

Un array es un vector, con muchas dimensiones, es una forma de guardar datos de forma momentanea en un proceso y acceder a ellos dentro del mismo proceso.

El primer array (array departamento), guardará en cada item el DEPARTAMENTO que se guarda de la persona en la tabla CLASIFICACION y en el segundo (array nivel ) , el NIVEL. Con ello conseguimos tener por cada persona la terna DEPARTAMENTO-NIVEL, cada una en un array.

Sólo nos queda hacer un bucle for que se repita un número de veces igual al número de items que tienen los arrays para ir llamando a la búsqueda NOTICIAS-PERSONAS sucesivamente e ir añadiendo los resultados de cada una de ellas a una cesta local, que al final procesaremos y será la que se muestra en el formulario.

Podeis descargarlo aquí http://forum.velneo.com/es/viewtopic.php?p=80270#80270

Vserver: prueba de stress

Después de leer este verano las pruebas de stress que se han realizado a los distintos bancos para ver si eran capaces de superar las crisis, se me ocurrió plantear una prueba del mismo tipo con el vServer.

La idea es sencilla. Crear una aplicación con una sola tabla pero con un número grande de registros y someterla a unas cuantas pruebas sencillas y ver cómo se comportaba.

Para ello creé una aplicación con las siguientes tablas

  • NAMES: tabla a la que importé nombres de personas. Indices Código y Nombre
  • APELLIDOS :  en ella importé un listado completo de apellidos. Indices Código y Nombre
  • PERSONAS:  la tabla con la que realicé las pruebas. Inices Código, Nombre, Palabras y Trozos

Un demonio llamaba a un proceso que daba de alta 3000 registros de cada vez en la tabla PERSONAS, escogiendo aleatoriamente , un nombre propio y dos apellidos.

Tras dejarlo cargado en el vServer unas 26 horas, se habían generado 4.689.000 registros.

Ficha técnica de la prueba

HARDWARE Y S.O.

Pentium Dual Core a 2,5 GHz y con 4 Gb de memoria RAM

Microsoft Windows Server 2003 standart edition  service pack 1

vServer versión 6.3.9

Registros en la tabla: 4.689.000

Tamaño del archivo .dat :     609.022 Kb

Tamaño del archivo .idx:  1.538.008 Kb

Realicé siempre las mismas pruebas:

  1. Búsqueda por código. Sencillo ,simplemente cargar la lista en pantalla con la opción de menú Búsqueda
  2. Una vez tenía el resultado anterior, reordenar por código
  3. Una vez ordenada por código, reordenar por Nombre

Además, realicé el paso 2 y el 3 una segunda vez sin cerrar el vClient, para ver si el comportamiento mejoraba tras las primeras ordenaciones.

Los resultados fueron estos

1. Búsqueda por código:   8 seg.

2. Reordenar por código: 1ª vez 8 min 40 seg    2ª vez 45 seg.

3. Reordenar por nombre: 1ª vez 12 min 15 seg    2ª vez 37 seg.

Tras estas pruebas, hice una regeneración de índices de la tabla que tardó en finalizar  5 min y 32 seg. Con ello esperaba una mejora significativa en los tiempos de las pruebas pero los resultados no produjeron mejoras dignas de mención.

ACTUALIZACION

Repetida la prueba en remoto, con el navegador atacando la aplicación en el vServer desde otro equipo

  1. Búsqueda por código  1 min 35 segundos
  2. Reordenar por código: 42 minutos 30 segundos.

NUEVA ACTUALIZACIÓN A 30-8-2010.

Prueba en local.

Siguiendo la sugerencia de Paco, he reducido el campo código a numérico de 3 cifras con los siguientes resultados

  1. Búsqueda por código:  8 segundos
  2. Reordenar por código: 7 minutos 3 segundos

Prueba en remoto

  1. Búsqueda por código : 1 minuto 5 segundos
  2. Reordenar por código: 40 minutos 5 segundos

    Nuevos tamaños de los archivos:

    • personas.dat    595.284 Kb
    • persona.idx  1.094.204 Kb
    A %d blogueros les gusta esto: