Tablas TADOTable en memoria

[Casimiro Noteví]

Empezado por JF Sebastian

[..] Lo costoso resulta realizar la búsqueda en el .mdb que reside en disco.[..]

¿Pero qué es lo que haces en esa búsqueda?

[JF Sebastian]

Mi aplicación consiste en el dimensionamiento óptimo de estructuras metálicas formadas por perfiles comerciales (barras). Las dimensiones y características de estos perfiles están en una base de datos .mdb

La base de datos consta de varias tablas, en la primera se almacenan las familias de perfiles disponibles (Laminados, Conformados, Extruidos...) en la segunda se almacenan los nombres de las series de perfiles (IPE, IPN, HEB,...) en la tercera se almacenan los perfiles en si (IPE_100,IPE_120,...), etc. En cada tabla hay campos de relacion ID que empleo para realizar un master-detail de modo que se pueda organizar la información. Además la tercera tabla está ordenada (IndexFieldNames) por un campo específico como puede ser el momento de inercia.

El dimensionamiento se realiza mediante un metodo metaheurístico (HS) de búsqueda, en el que se prueban aleatoriamente diversas configuraciones de perfiles, es normal hacer miles de búsquedas. Por cada búsqueda es preciso efectuar un cálculo algo complejo.

Antes de cada cálculo hay que leer de la base de datos las características de los perfiles de las barras de la estructura en la nueva configuración que selecciona el algoritmo HS (Esta configuración es un vector de enteros de dimensión el número de barras y en el que se almacena un número pseudoaleatorio comprendido entre 1 y el número de perfiles que haya en la tercera tabla ej: IPE_xxx). La estructura a su vez puede tener bastantes barras.

El cálculo esta muy optimizado en velocidad y prácticamente es instantáneo. El cuello de botella reside en leer de la base de datos el perfil aleatorio N dentro de la tercera tabla.

Cada barra tiene asociada una clase con la familia y grupo de perfil (entre otras muchas cosas); no cambian durante el cálculo, lo que varia es la dimensión del perfil.

En las pruebas que he hecho he intentado comentar los locate, first, last, next, prior, recno, etc y de 4 horas de tiempo total de cálculo pasó a 10 minutos.
Comentando además la lectura en sí del registro de la BD, aún más rápido pero no mucho más..

Llevo programando muchos años pero soy bastante profano en bases de datos.

[[Caral]]

Hola
Aqui solo veo 2 campos a buscar de 3 tablas.
Tabla T1 Campos TIPO, TipoPerfilId
Tabla T2 Campos NOMBRE, Perfil
Tabla T3 Campos NOMBRE, serie1

No entiendo por que se hace lento el proceso, esta consulta access la hace en fracción de segundos.

Hago consultas con mas tablas y mas campos y no tardan ni un parpadeo.
Para mi que algo estas haciendo mal ya que access no influye en esto.
Otra cosa: Jamas haría que la Tabla completa estuviera en memoria, se alentaría el programa y mucho menos para una simple consulta.
Access tiene un generador de consultas sql, ahí es donde puedes perfeccionar la como la necesites, solo copia y pega esa consulta en delphi y ya.
Saludos

[JF Sebastian]

He medido el tiempo que tarda en hacer la consulta con locate y es inferior a 0.05 s
Influye el master-detail en el tiempo de búsqueda con locate??
La tabla T3 tiene sólo unos 5000 registros pero con unos 40 campos

Un saludo

[Casimiro Noteví]

Empezado por JF Sebastian

He medido el tiempo que tarda en hacer la consulta con locate y es inferior a 0.05 s
Influye el master-detail en el tiempo de búsqueda con locate??
La tabla T3 tiene sólo unos 5000 registros pero con unos 40 campos
Un saludo

Entonces, en qué momento es lento?

[JF Sebastian]

Empezado por Casimiro Notevi

Entonces, en qué momento es lento?

Cuando en la tabla T3 hay unos cientos de registros activos por el master/detail
Cuando hay 20 registros tarda 7 minutos en realizar el cálculo completo
Cuando hay 200 registros tarda más de 120 minutos
Siendo en ambos casos la misma estructura y el mismo número de iteraciones, todo igual, solo variando el tipo de perfil a buscar entre el número indicado arriba (20 y 200)

[Casimiro Noteví]

Pues sí, haría falta ver cómo lo haces, precisamente el amigo que comenté antes tiene algo parecido pero para una fábrica de muebles de madera y necesita hacer lo mismo que tus cálculos para aprovechar lo mejor posible todo el material.
Y lo hizo en access con sql. Le pregunté y me ha dicho que no tiene ningún problema de velocidad. Lleva funcionando con ese programa desde hace unos 15 años y lo ha ido modificando y ampliando, incluso lo han instalado en otras fábricas de muebles y no se quejan de velocidad.
Así que sería necesario ver tu código, estructuras, etc. para poder echarte una mano.

[[Caral]]

Hola
Segun entiendo el Locate se hace con un AdoTable, es casi un filtro.
Esto se quiera o no trae todos los registros.
Con un AdoQuery el asunto es muy diferente, la velocidad es muy superior.
Saludos

[JF Sebastian]

Empezado por Caral

Hola
Segun entiendo el Locate se hace con un AdoTable, es casi un filtro.
Esto se quiera o no trae todos los registros.
Con un AdoQuery el asunto es muy diferente, la velocidad es muy superior.
Saludos

El problema es que necesito situar el cursor de la base de datos en el registro para poder leer todos los campos, son como ya he dicho unos 40.
Esto lo hago con locate.
He intentado hacerlo con AdoQuery, pero como necesito leer todos los campos tarda practicamente los mismo.

Por cierto, he tenido problemas para localizar un campo integer con locate, ¿Sólo busca textos?

[Casimiro Noteví]

Si te digo la verdad... no entiendo la situación, dices que tarda 120 minutos en hacer qué?, en hacer un cálculo (o un millón de cálculos), en recorrer 200 registros (pero cuántas veces), y el cálculo ese cuánto tarda, cada uno?.

[JF Sebastian]

Gracias por vuestras respuestas.

Al final he creado una clase que contiene para cada barra todos los perfiles de esa serie con un array of array dinámico.
El rendimiento en velocidad es unas 10 veces superior al de acceso a la base de datos. Como el cálculo es muy intesivo, merece la pena...

Un saludo