Como mejorar la velocidad en este caso....

[Alfredo]

Hola compañeros!


Tengo un problema que deseo compartir con ustedes:

Trabajo cun una base de datos de Paradox indexada por un codido unico (típico). en la tablita exite otro campo memo en el cual guardo una cantidad indeterminada de nombres y apellidos separados por comas, ejemplo:
PEDRO PEREZ, JUAN CUALQUIERA, MANUEL NOMEACUERDO...., NOMBE APELLIDO

Para buscar en cuantos proyectos trabajo alguien, mando una consulta asi:
select * from proyecto.db
where grupo like %nombreapellido%

donde nombre apellido es la string a buscar.

El caso es que tarda media vida en devolver los datos... :confused:

no puedo indexar por alli porque es un campo memo. Aunque creo haber leido que los tquerys no hacen uso de los indices(?perdonen si estoy rebusnando, y corrijanme)

El caso es que no puedo usar un campo string, porque en varios casos la lista de personas sobrepasa los 256 caracteres y en casos especiales pudieran aparecer en listas 150 personas (calculen a razon de 20 caracteres por persona).

Realmente quiciera implementar otro metodo o quiza forma de almacenar en la base de datos o lo que sea ..., se me ocurria algo como cun campo lookup a una tabla que se cargue con todas las personas, pero dudo en como inplantar la busqueda, el campo nombreapellido almasenaria una cadena como: 25,358,1208,5,10254
y creo que es la misma moneda vista desde otro angulo.........

Alguien tiene una mejor idea que esta ideota!

Se agracede el esfuerzo... y se aceptan sugerencias y regaños :D

[Casimiro Notevi]

y por qué no tienes una tabla con los nombres y su campo código, ese sería el índice que estaría relacionado con la tabla de proyectos


¿o acaso no he entendido bien el problema?

[marcoszorrilla]

Creo que la idea que te da Casimiro es buena, ya que el planteamiento actual es prácticamente inviable. En cuanto al tema índices, pues resulta que las consultas no los utilizan, yo al menos he hecho pruebas de rendimiento con índices y sin ellos y el tiempo era exactamente el mismo, (estamos hablando de Paradox).

Un Saludo.

[roman]

Yo también considero que el punto central aquí es el planteamiento de la estructura relacional. Y por lo que colijo, no se trataría de añadir sólamente la tabla de nombres sino además una tabla asociativa ya que parece que la relación entre proyectos y empleados es n-n.

Tendrías tus tablas:



empleados = (id, nombre)
proyectos = (id, descripcion)
asignaciones = (empleado_id, proyecto_id)


Para una búsqueda como la que mencionas, primero buscas el id del empleado:


select id from empleados where nombre like '%nombreEmpleado%'


Y usas el id obtenido para buscar en la tabla de asignaciones:


select proyecto_id from asignaciones where empleado_id = :empleadoId


Con lo que obtienes la lista de ids de los proyectos en que participó el empleado.

Por supuesto puedes usar joins para obtener directamente los proyectos, por ejemplo:


select proyectos.descripcion
from asignaciones
left join proyectos on proyectos.id = asignaciones.proyecto_id
where asignaciones.empleado_id = :empleadoId


o directamente con el nombre del empleado:


select proyectos.descripcion
from asignaciones
left join empleados on empleados.id = asignaciones.empleado_id
left join proyectos on proyectos.id = asignaciones.proyecto_id
where empleados.nombre like '%nombreEmpleado%'


En cualquier forma que uses ten en cuenta que la búsqueda con like puede devolverte más de un registro.

Por otra parte, tal como comenta Marcos, Paradox no parece hacer uso de los índices en consultas SQL. Por ello, contrario a lo que se recomendaría en servidores SQL, en bases de escritorio resulta mucho más eficiente usar componentes TTable en lugar de TQuery, sobre todo si tus tablas son muy grandes.

Para este caso, por ejemplo, podrías tener componentes tblEmpleados, tblProyectos y tblAsignaciones.

Poniendo a tblEmpleados como master de tblAsignaciones, en cuanto localices al empleado (con tblEmpleados.Locate o tblEmpleados.FindKey si tienes un índice sobre el campo nombre), la componente tblAsignaciones automáticamente se filtrará con únicamente las asignaciones del empleado.

Semánticamente es lo mismo que hacer la relación por SQL pero más eficiente.

// Saludos

[Alfredo]

Les agradezco a todos las ideas... voy a hacer ambas pruebas... en el caso de las consultas las pasare a FB... y las mantendre para probar con Ttables... luego comento... :D