6.7.5 Método Alternativo

Aunque este método no se ha implementado, parece más potente que el comentado anteriormente. Sin embargo, por falta de tiempo, queda propuesto como una posible mejora futura. Este método se basa en realizar la consulta exactamente como se hace ahora, es decir, sin modificar, directamente lo que daría el Traductor a SQL. Después se crea dinámicamente una tabla temporal (directamente con SQL), aprovechando la potencia de SQL y ODBC, que contenga el resultado de la consulta. Después, habría que montar una nueva consulta pero que se ejecute sobre esta tabla recién creada. El resultado final se meterá en una tabla de nombre Q_i. Veamos un ejemplo.

Consulta Original:

SELECT DISTINCT BARCOS.Nombre,
BARCOS.Velocidad_Máxima
FROM BARCOS
WHERE BARCOS.Desplazamiento >3

Función interna:

FINT=SUPERLATIVO, MAX, 5
CAMPO=BARCOS.Velocidad_Máxima

Los pasos a seguir son:

1)  Crear una tabla Temp con el resultado de la consulta:

CREATE TABLE Temp(Nombre TEXT, Eslora INTEGER, VelocMáxima INTEGER)

2) Introducir en la nueva tabla los datos obtenidos en la consulta:

INSERT INTO Temp
SELECT DISTINCT BARCOS.Nombre, BARCOS.Velocidad_Máxima
FROM BARCOS
WHERE BARCOS.Desplazamiento >3

3) Crear una tabla cuyo nombre sea el de la consulta, Q_i en este caso:

CREATE TABLE Q_i(Nombre TEXT, Eslora INTEGER, VelocMáxima INTEGER)

4) Introducir en Q_i el resultado final de la consulta:

INSERT INTO Q_i
SELECT TOP 5 Nombre, Velocidad_Máxima
FROM Temp
ORDER BY Velocidad_Máxima ASC

5) Eliminar la tabla temporal:

DROP TABLE Temp

Este método habría que utilizarlo para implementar correctamente las funciones COUNT y AVG, sin el riesgo constante de emplear cláusulas SQL incompatibles con ellas. De esta forma se independiza en mayor medida lo que genera el traductor y lo que debe hacer el ejecutor.

Con esto, el primer paso de creación de una tabla temporal que albergue la consulta original sería algo realmente muy simple ya que se basaría en la lista de campos del SELECT. Pero como puedes ver, necesitamos una lista con TODOS los nombres de los campos de la base de datos y el tipo de cada uno de ellos para crear una tabla con campos compatibles.

El segundo paso, la introducción de los datos de la consulta en la nueva tabla, sería inmediato ya que es la propia consulta SQL creada por el traductor pegándole al principio INSERT INTO tabla.

El tercer paso es idéntico al primero sólo que ahora creamos una tabla con el nombre de la consulta que estamos realizando.

El cuarto paso ya depende de la función interna que se quiera implementar. He puesto el caso de un superlativo y como verás, es realmente simple.

El paso de eliminación de la tabla temporal de la base de datos es también algo muy trivial. En el cuarto paso hay que implementar lo que es realmente la función interna. Más o menos, se tiene que hacer de la siguiente forma:

• Para el caso la función PROMEDIO, la consulta sería:

INSERT INTO Q_i
SELECT AVG(campo)
FROM Q_j

Debemos tener cuidado en este caso ya que las tablas Temp y Qi que crearemos no serán idénticas. En este caso, Q_i solamente debería tener un campo, mientras que Temp, en general, puede tener más campos.

• Para el caso de la función CUENTA, la consulta sería:

INSERT INTO Q0
SELECT COUNT(campo)
FROM Temp

Aquí pasa lo mismo que antes, las tablas Temp y Q_i no tienen porqué ser iguales.

• Para el caso de la función UNIDADES, la consulta sería:

INSERT INTO Q_i
SELECT Campo1*factor, Campo2, Campo3, ...
FROM Temp

Aquí sí que las tablas Temp y Q_i son iguales.

Esta forma de funcionamiento es muy interesante porque podemos olvidarnos de implementar mediante el código funciones que anden navegando por los resultados de las consultas. Además, como ya se ha visto, crear una tabla de forma dinámica directamente con SQL es algo realmente simple, con lo cual, podemos guardar los resultados finales de nuestras consultas Q0, Q1, ... en tablas de Access directamente. De esta forma, además de aprovechar la potencia que nos pueda dar el motor de Access, podemos utilizar estas nuevas tablas para implementar directamente las funciones binarias, de forma que sigan siendo consultas SQL pero que manejen nuestras nuevas tablas, aumentando así de forma considerable el rendimiento del sistema.

Habría un problema que en realidad no lo sería tanto. Cuando creamos una tabla nueva, se ha utilizado el nombre original del campo que sea en nuestra base de datos. Es decir, si tuviéramos una consulta del tipo:

SELECT OBUSES.Calibre, CAÑONES.Calibre
FROM OBUSES, CAÑONES
WHERE ........

Tendríamos un pequeño problema al intentar ejecutar:

CREATE TABLE Q1 (Calibre as INTEGER, Calibre as INTEGER)

Es decir, habría que sustituir internamente los nombres de los campos, por ejemplo Campo1 y Campo2, y mantener una tabla interna de traducción que nos informe que Campo1 se está refiriendo a OBUSES.Calibre y Campo2 a CAÑONES.Calibre.

Anterior   I  Siguiente   I  Índice capítulo 6   I  Índice General