7 respuestas en este tema

[erikmx]

Hola buenas noches a todos, por cuestiones ajenas a mi me surgio la siguiente problematica, como consultar un dato o palabra, dentro de una tabla en todos los campos, es decir supongamos que la estructura es la siguiente:

[NOMBRE],[APEPATERNO],[APEMATERNO],[DIRECCION],[TELEFONO],[NOTAS]

Mi programa esta hecho en delphi y tengo una caja de texto donde meterian una palabra, pero como esta consulta debe ser generica, ya que debera poder usarce en varias tablas, pero por el momento supongamos que es solo una, como no puedo poner una caja combo para saber en que campo buscar debo hacer una consulta que recorra cada campo, que busque si algun registro tiene ese texto, y lo haga en todos los campos.

Supongamos que en la caja alguien escribe "BLANCO"

Puede haber un apellido que sea "blanco", en la direccion puede haber otro con "porton blanco" y en notas puede haber el texto "vehiculo blanco", alguien tiene una idea de como realizar una consulta donde por una palabra me busque ese dato en todos los campos y me los seleccione??

Nota: se que puede ser poco viable porque seria muy lento, y que no es para nada optimo el funcionamiento como hacerlo en un lugar especifico, pero por lo menos quiero ver y demostrar que comparado con una consulta directa en un campo especifico se obtiene un mejor resultado que buscando en cada uno de los registros y cada uno de los campos.

Ojala alguien tenga alguna idea de como hacerlo

[Sergio]

En FireBird podrias usar algo asi:

select * from tabla where campo1||campo2||campo3 like '%BLANCO%'

O si no quieres preocuparte de mayusculas:

select * from tabla where upper(campo1||campo2||campo3) like '%BLANCO%'

O equivalentmenete:

select * from tabla where (upper(campo1) like '%BLANCO%') or (upper(campo2) like '%BLANCO%') or (upper(campo3) like '%BLANCO%')

Pero por lo que se, tu has de tener una lista de campos a usar para cada tabla y montar la SQL a la medida de la tabla, no creo que una SQL generica te vaya a funcionar y si lo hace... comprale un libro de sudokus a tu cliente!

Yo tengo algo similar (y corre bastante, es "usable") y para cada tabla guardo el campo clave y los 5 o 6 campos por los buscaré, y si algún cliente se queja de que quiere poder buscar por un trozo del número de telefono, pues añado el telefono a la lista y arreglado.

[erikmx]

Muchas gracias Sergio, voy a probar lo que me proporcionaste, efectivamente las busquedas genericas son extremadamente lentas, pero los clientes o los jefes necesitan verlo para creerlo 

En mi caso cuando son tablas con muchos campos y muchos registros trato de indexar lo mejor y mas logicamente posible, despues trato de poner cajas de busqueda de los campos mas importantes (con indices), usando LIKE porque luego les da flojera escribir completas las palabras  y el resultado usualmente es muy rapido

Pero en este caso no quieren muchas cajas de texto con los campos si no que quieren una sola y que el programa por arte de magia les devuelva un resultado.

Algo curioso en una ocacion tenia una tabla con unos 200,000 registros con mas o menos 15 campos, tenia un indice del tipo Nombre,Materno,Paterno y era extremadamente rapido, pero cuando me dijeron debia de mostrar los datos ordenados como FechaCaptura,Nombre,Paterno,Materno el tiempo de mostrar los datos aunque fueran unos 5 o 6 se tardaba casi un minuto, puedo pensar que era porque tenia que buscar en toda la tabla e ir ordenando por fecha antes de mostrar los datos, al final segui mostrando los datos en el orden normal y volvio a funcionar casi instantaneo, en fin, un saludo

[erikmx]

Muchas gracias Sergio, ya probe con tu ejemplo de consulta, pero en MySQL no me funciono como tal ves les funciona en Firebird ya que utilizando el mismo ejemplo:

SELECT
*
FROM
directorio
WHERE
directorio.numero||directorio.nombre||directorio.paterno||directorio.materno||directorio.notas LIKE '%TOYOTA%'

De 50,000 registros me muestra practicamente los 50,000 registros, como si solo ejecutara "SELECT *"

Alguna idea de porque en MySQL no lo hace 

[Rolphy Reyes]

Saludos.

Puedes probar con la opción equivalente que Sergio te mostró, usando la clausula OR.

Una opción que me parece viable es usar Full Text Search, que de momento Firebird (por mala suerte) no posee de manera nativa.

Info.

[Sergio]

Yo uso la opción del OR, es mejor porque permite que cada campo indexe por lo que tenga a mano, si sumas los camos no hay indice que te ayude.

La velocidad de respuesta es de milesimas de segundo, o decimas, el caso es que en nuestro caso, lanzamos el refresco si no pulsa nada en 0.5 segundos, y es casi inmediato.

Tenemos un butón de "mas" que si lo pulsan, usamos:

(CAMPO1 LIKE '%TEXTO%) OR...

...pero si no está pulsado busca que empiecen por, lo que si tienes indices es inmediato:

(CAMPO1 LIKE 'TEXTO%) OR...

Supongo que en cualquier motor es mejor usar la estrategia de los ORs, yo probaría con eso, que no implica casi trabajo.

Archivos adjuntos

•  4465_ab4df5b35773d7ac5350249ce3bd45d993b08d32.png   7,75KB   4 descargas

[erikmx]

Muchas gracias por sus comentarios, de hecho en algunos casos si habia utilizado "OR" en mis consultas pero no con todos los campos que yo preseleccione.

En este caso queria saber si no habia una forma de implementar una consulta que buscara un dato independientemente de conocer que campos contiene esa tabla.

Saludos 

[genriquez]

Hola

En lo que comentas del obtener el resultado con ordenamiento, efectivamente el motor se demora más debido a que debe seleccionar y ordenar, mientras que de la otra forma, solo toma los registros y los muestra en el orden nativo de la base de datos.

Te recomiendo el uso del OR como lo dice Sergio, dado que puedes personalizarlo fácilmente para uno o varios campos.  si puede usar la instrucción Full Text Search, creo que daría mejor resultado.

Otra técnica es utilizar previamente la función Soundex  para crear índices de cada palabra con la llave del registro donde se encuentra,  así puedes filtrar por el índice que genera soundex para buscar en menos registros, esto podría mejorar la búsqueda.

sin embargo la experiencia me dice que esta técnica es buena cuando requieres manejar muchos registros por tabla,  creo que para 200.000 e incluso menos de 1 millón no vale la pena el esfuerzo.

Saludos.