Cita: @max_mouse699: Esta consulta que usa no tiene errores de sintaxis.
@gnzsoloyo: entiendo tu punto, pero lo que mencione, lo mencione para que el usuario programe de mejor manera, asi sera mas facil y rapido para el usuario detectar algun error en la construccion de la consulta. Ahora, lo que mencione, tambien lo hice porque me gusta respetar el como se debe escribir un codigo, aunque tengo claro que en php hay mucha libertad en cuanto a la escritura de su cpdigo, y que se pueden escribir directamente sus variables en la construccion de una query. Mas abajo explicare de mejor manera el porque lo mencione.
Cita: @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í:
Primero: entiendo tu ironia, y si te molesto, te pido disculpas. Pero en muchas oprtunidades me he encontrado con personas que cuando uno le habla de una manera asumiendo que entienden, despues de largos post, te das cuenta de que la base de ese concepto nos les queda del todo claro, como me paso a mi con una confusion que tuve con los joins, y que recuerdo muy bien que gnzsoloyo ,e lo aclaro. Persona si te molesto.
Cita: 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.
Segundo: asi mismo como pusiste el ejemplo, es lo que quiero evitar, que si el usuario no pone ninguna variable, o si la variable es NULL, que mejor esa parte de la instrccion desaparezca, en ves de que aparezca y que tal cual como tu indicas, se convierta en una consulta ineficiente.
Cita: 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í
es decir, SÓLO AGREGAR LA CONDICIÓN CUANDO REALMENTE SE NECESITE.:
Tercero: Es precisamente lo que queria decir, asi tal cual como tu pones el ejemplo, eso es lo que queria mencionar.
Cita: 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.
Cuarto: Gracias por el consejo, de verdad que no lo sabia, he aprendido algo nuevo gracias a ti.
Lo que queria mencionar con respecto a la escritura de la consulta, y a la correcta escritura, es que si el usuario escribe como ustedes lo indican, tendria que controlar el uso de las comillas, y tendria que controlar si los caracteres escritos en la consulta son los correctos o no.
En cambio, si lo escribe como en su oprtunidad lo propuso leonardo_josue, que concatenara la construccion de la consulta:
Código:
query_a = "SELECT * FROM" . tabla . "WHERE campo LIKE '%" . valor . "%'";
o de lo contrario
query = "WHERE campo LIKE '%" . valor . "%'";
query_b = "SELECT * FROM" . tabla . " " . query;
no se tendria que preocupar ni de las comillas, ni de los caracteres, debido a que todo lo tomaria como string, de lo unico que se tendria que preocupar es de que la variable no contenga una comilla simple, que eso romperia la consulta, y llevaria a error, el resto es preocuparse de que los valores lleguen mediante las variables. Incluso, si lo pueden apreciar, lo puede hacer de la otra forma, y la consulta estaria en una buena construccion.
Eso es lo que propuso leonardo_josue, el cual le encontre toda la razon. Ahora si lo deja como ustedes lo indican, seria un problema a la hora de
detectar un error posible en la consulta, debido a que no quedaria a la vista y bastante claro para el programador, que el error es problema de la consulta, debido a que seria mas notorio darse cuenta que en una consulta me falta un LIKE, a que empezar a revisar la consulta, y descubrir que en realidad el LIKE esta bien, pero no le paso ningun valor.
Espero haberme explicado bien.
Saludos.