Construcción dinámica de SQLs. ¿Qué es mejor?

[Tino]

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í:

 
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;

Otra posible manera, sería:

 
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;

Es decir, la 1a. manera emplea la función Format y la 2a. manera genera parámetros al vuelo.

¿Qué es mejor? ¿Hay una mejor alternativa en generar SQL dinámicamente?

Saludos.

[delphi.com.ar]

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!

[Mick]

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

[delphi.com.ar]

Empezado por Mick

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.

Creo que en los dos casos estas expuesto a situaciones de esa índole.

Saludos!

[Tino]

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.

[delphi.com.ar]

Empezado por Tino

...no entiendo porque la 1a. manera no es tan SQL estándar como la 2a...

Simplemente intenta pasar una fecha a dos motores de la primer manera, vas a tener que darle un formato o utilizar una alguna función no ANSI específica de cada motor, con el uso de parámetros simplemente te olvidas de ese problema.

Saludos!