FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
Construcción dinámica de SQLs. ¿Qué es mejor?
Hola al foro.
Tengo interés en saber vuestra opinión sobre 2 maneras de realizar consultas SQL dinámicas que conozco y que quiero decantarme por una de ellas. Yo, y en contra de lo que suelo ver, genero el texto SQL así: Código:
const SQLSelect1 = 'SELECT CAMPO FROM TABLA WHERE CAMPO1= %d AND CAMPO2=''%s'''; begin with TSQLQuery.Create do .... SQL.Text := Format(SQLSelect1, [p1, p2]); Open; .... end; Código:
const SQLSelect1 = 'SELECT CAMPO FROM TABLA WHERE CAMPO1= :param1 AND CAMPO2=:param2'; begin with TSQLQuery.Create do .... SQL.Text := SQLSelect1; Params[0].AsInteger := v1; Params[1].AsString := v2; Open; .... end; ¿Qué es mejor? ¿Hay una mejor alternativa en generar SQL dinámicamente? Saludos. Última edición por Tino fecha: 12-07-2004 a las 22:31:22. |
#2
|
||||
|
||||
De estas opciones, sin lugar a dudas, la mas óptima y portable es la segunda.
Por ejemplo, en Oracle, las consultas SQL se guardan momentaneamente compiladas en el "shared pool". Al momento de ejecutar una nueva consulta, busca si ya tenía parseado+compilado este código en este cache, si lo enecuentra lo ejecuta evitándose ejecutar los pasos recien nombrados lo que acelera notablemente la ejecución. Si las consultas fueron definidas con "Bind Paramenters" (los parámetros de Delphi), podrá encontrar la misma consulta en el "sared pool" si la consulta fue definida con parámetros estáticos entonces para el motor se trata de diferentes consultas. Por otro lado, usar parámetros hace que nuestro código sea fácilmente portable a diferentes motores de bases de datos, siempre que respetemos el ANSI SQL. Saludos!
__________________
delphi.com.ar Dedique el tiempo suficiente para formular su pregunta si pretende que alguien dedique su tiempo en contestarla. |
#3
|
|||
|
|||
Solo añadir que otra desventaja de utilizar la primera opcion es que provoca un agujero de seguridad ya que permite utilizar ataques de inyeccion de SQL, que podrian permitir a un usuario malicioso acceder a datos que en teoria no deberia
poder ver o en el peor de los casos incluso borrar tablas enteras. Saludos Miguel |
#4
|
||||
|
||||
Cita:
Saludos!
__________________
delphi.com.ar Dedique el tiempo suficiente para formular su pregunta si pretende que alguien dedique su tiempo en contestarla. |
#5
|
||||
|
||||
Una respuesta aclaradora
Gracias por la respuesta, aunque no entiendo porque la 1a. manera no es tan SQL estándar como la 2a. Yo la veo igual en ese sentido. ¿Las comillas quizás?
Lo del shared pool si que es un detalle muy revelador y que voy a tener en cuenta. Gracias. Sin embargo, se me ocurre un caso real en que igual es recomendable la 1a. manera o incluso una mezcla de ambas. Si el número de condiciones o de tablas o de columnas es variable, la función Format nos puede echar una mano para formar la cadena de texto SQL final. Creo que lo mejor entonces es emplear la 1a. manera cuando el texto se vuelve demasiado variable y emplear bind parameters para aprovechar su eficiencia. En los casos más sencillos usar la 2a. ¿Qué decís? Un saludo. |
#6
|
||||
|
||||
Cita:
Saludos!
__________________
delphi.com.ar Dedique el tiempo suficiente para formular su pregunta si pretende que alguien dedique su tiempo en contestarla. |
|
|
|