Ejemplo Nº 049 – Usando DISTINCT

9 comentarios

Cuando escribes un SELECT tienes la posibilidad de decirle que deseas que te devuelva todos los resultados o solamente aquellos que son distintos a los demás.

Por ejemplo, supongamos que deseamos conocer todas las unidades de medida utilizadas por nuestros productos. La columna donde se guarda ese dato se llama PRD_UNIMED.

SELECT
   DISTINCT
   PRD_UNIMED
FROM
   PRODUCTOS

La cláusula DISTINCT le obliga al Firebird a mostrarnos solamente una vez a cada unidad de medida. Eso quiere decir que aunque haya 240 productos cuya unidad de medida sea KLG (kilogramos) la palabra KLG aparecerá una sola vez en el resultado. ¿Por qué? porque escribimos la cláusula DISTINCT.

En la tabla VENTASCAB guardamos los datos de cabecera de cada venta realizada (sucursal, fecha, identificador del cliente, etc.), ¿cuáles son los años que tenemos registrados en esa tabla? ¿se encuentran allí las ventas que hicimos en el año 2006?. Lo podremos saber fácilmente con este SELECT:

SELECT
   DISTINCT
   EXTRACT(YEAR FROM VTC_FECHAX)
FROM
   VENTASCAB

cada uno de los años de las ventas registradas aparecerá una vez y solamente una vez. Por ejemplo, podríamos obtener:

2008
2009
2010
2011
2012
2013

entonces, aunque la tabla VENTASCAB tenga miles y miles de filas solamente veríamos 6 filas, las que corresponden a cada uno de los años en que se registraron ventas.

 

Algo más sobre PLAN

5 comentarios

En este artículo:

https://firebird21.wordpress.com/2013/04/30/usando-un-plan/

se explicó lo que es un PLAN y como utilizarlo con la sentencia SELECT pero faltó aclarar que no solamente se lo puede usar con la sentencia SELECT sino también con las sentencias DELETE y UPDATE.

Por ejemplo, supongamos que tenemos una Primary Key compuesta por las columnas PRD_CODSUC (código de la sucursal) y PRD_IDENTI (identificador del producto) y queremos aumentar el precio de venta de todos nuestros productos de la sucursal número 0 en un 5%, entonces podríamos escribir algo como:

UPDATE
   PRODUCTOS
SET
   PRD_PREVTA = PRD_PREVTA * 1.05
WHERE
   PRD_CODSUC = 0
PLAN
   (PRODUCTOS INDEX (PK_PRODUCTOS))

para forzarle al Firebird a utilizar el índice de la Primary Key. Si no lo forzamos entonces él podría utilizar otro índice (por ejemplo, el de una Unique Key o cualquier otro índice).

¿Cómo se puede saber cuál PLAN se usa afuera de un trigger?

Saber cual PLAN se usa en una sentencia SELECT, DELETE o UPDATE que está fuera de un trigger es muy fácil:

    • Si estamos usando ISQL, escribimos SET PLAN; y será la primera línea que veamos a continuación de un SELECT, DELETE o UPDATE
    • Si estamos usando EMS SQL Manager hacemos click sobre “Explain query” (como se explicó en el artículo cuyo enlace está arriba)

¿Cómo se puede saber cuál PLAN se usa dentro de un trigger?

Ni ISQL ni EMS SQL Manager nos dirán cual es el PLAN que se usó dentro de un trigger. Pero hay algo que podemos hacer para saberlo:

    • Extraemos el contenido del trigger y lo ponemos en un EXECUTE BLOCK o si estamos usando EMS SQL Manager, hacemos click sobre “New SQL Editor” (o presionamos las teclas Shift + F12) y copiamos allí el contenido del trigger
    • Ejecutamos el EXECUTE BLOCK o el Editor SQL y verificamos cual fue el PLAN utilizado

Conclusión:

Si sabes cual PLAN utilizó el Firebird entonces puedes entender cual fue su “razonamiento” y en algunos casos mejorarlo. Esto es muy importante cuando descubres que la operación que realizaste (SELECT, DELETE, UPDATE) se ejecutó lentamente porque el Firebird utilizó un índice inadecuado; si ese es el caso tienes la posibilidad de obligarle a usar otro índice y eso lo haces con la cláusula PLAN.

En síntesis, escribirías la cláusula PLAN cuando quieres que el Firebird utilice el índice que tú quieres que utilice, no el índice que el Firebird utilizaría por su cuenta.