TOP, Binding y registros


Estaba conversando con un amigo, sobre la necesidad que se nos han planteado en los últimos meses de contar en nuestras aplicaciones GeneXus con sentencias de SQL dinámico que se generen con variables y no con strings como lo hacen hoy (esta explicado con mas detalle en este post).

Lo que comentábamos era que pasamos muchos años sin tener for each con when (que es lo que genera el SQL dinamico).
 
Desde hace unos años contamos con el when  y ahora nos surgen nuevas necesidades para agregarle variables, de forma de consumir menos recursos (CPU) para no tener que recompilar la sentencia cada vez que se ejecuta.

La pregunta obvia es: ¿Como nos arreglabamos antes?

Creo que hay varias respuestas. En primer lugar, las bases de datos tenian menos registros, por lo que era mas facil lograr que las aplicaciones funcionaran correctamente y que los servidores de base de datos bancaran la carga. 

Haciamos mas programas. El poder tener sentencias con diferente ordenes, con diferentes condiciones que puedan ser resueltas en forma razonable por la base de datos, posibilito que con un mismo programa se pudieran resolver requerimientos que antes necesitaban varios programas. 

Los usuarios son mas exigentes. A medida que pasa el tiempo los usuarios de nuestras aplicaciones piden mas funcionalidades y con exigencias de performance mayores.  


SELECT TOP( ) 
Viendo el problema de limitar que un usuario no pueda hacer consultas que consuman demasiados recursos en el servidor de base de datos, perjudicando al resto de la aplicación esta la de limitar la cantidad de registros que una consulta puede recuperar. 

La forma mas facil que veo es agregar a la sentencia SQL lo necesario para que no traiga solamente los que se quieran (por ejemplos 1000) y aunque el usuario ponga una consulta con unos filtros que puedan traer muchisimos registros, solo traer los 1000 primeros que trae la misma.

Por ejemplo: 

for each att
   limit 1000
    --codigo
endfor

Esto generaria para SQL server (la sintaxis es diferente para los diferentes dbms)

selct TOP 1000 att from table order by att

Se que este problema esta simplificado y no es aplicable a todos los casos, porque hay excepciones donde eso no se puede usar (por ejemplo cuando los filtros se resuelven en el cliente, donde deberia dar un warning y seguir haciendolo como hoy).  

De cualquier forma es un cambio que nos permitiria tener menos programas, porque hoy muchas veces tenemos que hacer diferentes consultas o listados solo para evitar que un usuario despistado (o con mala leche) no pueda ejecutar consultas que devuelvan muchos registros.

y dentro de unos años, estaremos nuevamente comentando que ahora que tenemos el TOP estamos pidiendo el ________ (ponga usted lo que quiera) porque la historia volverá a repetirse, con aplicaciones cada vez mas grandes y complejas.

Comentarios

  1. Se puede hacer algo similar con el skip count

    ResponderBorrar
    Respuestas
    1. Si, en las versiones actuales de GX hay funcionalidades que aun no existian.
      Es bueno ver que en 14 años, hemos mejorado mucho en la potencia de las cosas que podemos hacer.

      Borrar
    2. Te felicito por este blog. Realmente esta muy bueno el contenido. Saludos!

      Borrar

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

Aplicación monolítica o distribuida?

La nefasta influencia del golero de Cacho Bochinche en el fútbol uruguayo

Funcionalidades de GeneXus que vale la pena conocer: DATE Constants.