Ver Mensaje Individual
  #7 (permalink)  
Antiguo 21/06/2013, 08:03
leonardo_josue
Colaborador
 
Fecha de Ingreso: enero-2007
Ubicación: México
Mensajes: 2.097
Antigüedad: 17 años, 4 meses
Puntos: 447
Respuesta: Problemas con consulta SQL

Hola de nuevo:

Cita:
@leonardo_josue: El que haya utilizado esa sintaxis en su consulta, es correcto. Te explico. Los simbolos %% que esten contenidas en una palabra, hara que mysql compare buscando en el campo especificado, si esa palabra se encuentra contenida en alguna parte del campo, es decir, si por ejemplo tu especificas el campo empresa, y por ejemplo deseas buscar todas las empresas que comiencen con "poer" (por darte un ejemplo), mysql buscarac en el campo empresa todas las filas que contengan la palabra poer. Asi, los valores validos entregados por la consulta pueden ser:

- poertuni
- kupoer
- aspoertuber

Si te fijas, cada una de las opciones entregadas contiene en si la palabra poer dentro de la conntruccion del nombre completo. Por ultimo, esos simbolos en las consultas de MySQL, se llaman comodines.
@max_mouse699: Gracias por la lección sobre el uso del LIKE ... sé perfectamente como funciona y para qué sirven los comodines, lo que quiero hacerle notar a eprado es que hacer una consulta donde el resultado de la concatenación sea una cadena que quede así:

Código:
...
campo LIKE '%%'
...
es decir, sin que la cadena contenga otra cosas mas que los dos símbolos de porcentaje ES COMPLETAMENTE INUTIL. Este caso puede ocurrir si por ejemplo las variables/parámetros vienen como NULL, la concatenación quedará exactamente como la puse arriba, sin embargo, y lo hago notar en mi post. Esta tipo de consultas es TERRIBLEMENTE INEFICIENTE, en todo caso es mejor omitir dicha condición de la consulta... a final de cuentas, el resultado de poner una condición como la pongo arriba o no poner ninguna condición ES EXACTAMENTE LO MISMO. Sin embargo, al poner la condición estás obligando al DBSM a buscar de manera exhaustiva algo que por defecto es verdadero.

Código MySQL:
Ver original
  1. mysql> SELECT * FROM tabla WHERE campo LIKE '%%';
  2. +------+-------------+
  3. | id   | campo       |
  4. +------+-------------+
  5. |    1 | poertuni    |
  6. |    2 | kupoer      |
  7. |    3 | aspoertuber |
  8. |    4 | otro valor  |
  9. +------+-------------+
  10. 4 rows in set (0.00 sec)
  11.  
  12. mysql> SELECT * FROM tabla;
  13. +------+-------------+
  14. | id   | campo       |
  15. +------+-------------+
  16. |    1 | poertuni    |
  17. |    2 | kupoer      |
  18. |    3 | aspoertuber |
  19. |    4 | otro valor  |
  20. +------+-------------+
  21. 4 rows in set (0.00 sec)

Si estás seguro que las variables/parámetros SIEMPRE VAN A CONTENER UN VALOR entonces puedes ignorar mi comentario, pero si por lo contrario, ES POSIBLE QUE TUS VALORES VENGAN COMO NULL es mejor que hagas una verificación previa, algo así:

Código:
consulta = 'SELECT campos FROM TABLA WHERE 1=1 '
SI $buscarEsta ES DIFERENTE DE NULL
    consulta = consulta + 'AND campo LIKE '%$buscarEsta%'
es decir, SÓLO AGREGAR LA CONDICIÓN CUANDO REALMENTE SE NECESITE.

Además, en la medida de lo posible hay que evitar las consultas donde utilizas comodines en ambos lados de la palabra a buscar, como es el caso. INSISTO, ESTO ES TERRIBLEMENTE INEFICIENTE.

Es preferible utilizar la función INSTR()... el resultado también sería el mismo, pero tiene un mejor rendimiento. Utilizando el mismo ejemplo que colocas en tu post te muestro a qué me refiero:

Código MySQL:
Ver original
  1. mysql> SELECT * FROM tabla WHERE campo LIKE '%poer%';
  2. +------+-------------+
  3. | id   | campo       |
  4. +------+-------------+
  5. |    1 | poertuni    |
  6. |    2 | kupoer      |
  7. |    3 | aspoertuber |
  8. +------+-------------+
  9. 3 rows in set (0.01 sec)
  10.  
  11. mysql> SELECT * FROM tabla WHERE INSTR(campo, 'poer') > 0;
  12. +------+-------------+
  13. | id   | campo       |
  14. +------+-------------+
  15. |    1 | poertuni    |
  16. |    2 | kupoer      |
  17. |    3 | aspoertuber |
  18. +------+-------------+
  19. 3 rows in set (0.00 sec)

Con pocos registros, la diferencia en los tiempos de respuesta puede no ser significativa (apenas 1 centécima de segundo en este caso) pero cuando tienes muchos registros en tus tablas la diferencia en rendimiento es considerable.

gnzsoloyo hace un perfecto resumen de todo lo que planteamos en nuestros posts:

Cita:
Si se producen errores no se debe a eso sino al contenido de las variables, que puede estar vacías o contener caracteres que la rompan.

Personalmente no soy partidario de abusar del LIKE de esta forma, y menos aún de tantas condiciones mandatorias, pero la sintaxis no es el problema. Son los parámetros.
Saludos
Leo.

Última edición por leonardo_josue; 21/06/2013 a las 10:19