31 respuestas en este tema

[pcicom]

SIMPLE...  Tarde pero llegue..

sql

SELECT MIN(fecha) AS primera,MAX(fecha) AS ultima FROM tabla

[luk2009]

SIMPLE...  Tarde pero llegue..

sql

SELECT MIN(fecha) AS primera,MAX(fecha) AS ultima FROM tabla

Pues la verdad es que como dices es mas facil  y uno haciendo uniones y demas pend..............

[Delphius]

Luk2009,
¿Seguro que esa consulta funciona? La he probado y me indica que hay un error justo en el select después de ese paréntesis.

pcicom la consulta que muestras podría llegar a ser válida en el eventual caso en que tanto Min() como Max() coincidan con el primer y último registro. Min() no devuelve el primer registro, sólo el mínimo y Max() no regresa el último sino el máximo.
Puedes estar ubicados en cualquier ubicación.
Es sólo coincidencias y una casualidad de que se dieran casos en los que Min() = primero y Max() = último. Nada impide que el mínimo y/o el máximo estén en el medio.

La ordenación de los registros depende de los índices activos y es sólo a efectos visuales. Internamente se podría decir que los datos son almacenados siguiendo una estructura árbol, luego estos al momento de mostrarse reciben la forma tabular (que tan acostumbrados estamos a ver... quizá por ello es tan fácil asumir que los datos son guardados secuencialmente) y el orden de cada registro dependerá de los índices.

La consulta que yo he colocado debe refinarse para adaptarse del mejor modo posible a las necesidades y usos. Por ello si bien canté victoria en su momento aclaré que necesita evaluarse si es realmente lo que se busca. Sobre todo si existen otras posibles operaciones sobre la tabla y que requieren un tratamiento basado en otros campos.

Saludos,

[Marc]

Hola.

Pensaba que ya estaba resuelto. No acabo de entender bien el problema, pero creo que te deberías quedar con una de estas dos consultas

select (select min(fecha) from tabla) as primera,
        (select max(fecha) from tabla) as ultima
from rdb$database;

o bien

select (select first 1 fecha from tabla order by id) as primera,
        (select first 1 fecha from tabla order by id desc) as ultima
from rdb$database;

El campo ID es la clave primaria, de esta forma esta consulta devuelve la fecha del primer registro entrado en la tabla y el del último registro.

La consulta principal se hace sobre rdb$datbase porqué esta es una tabla de sistema, que siempre existe y está disponible (contiene datos de la base de datos) y solo tiene un registro. Por lo que solo obtendremos una fila como resultado, con los datos de las dos subconsultas.

En el primer caso debes añadir un índice ascendente y otro descendente para FECHA, y en el segundo tienes que añadir un índice descendente para ID (o como se llame el campo de tu clave primaria), puesto que el índice ascendente ya lo creo el sistema al ser clave primaria.

Saludos.

[Delphius]

Hola Marc,
He probado la primera opción que mencionas, aprovechando que tengo ya ambos índices en el campo FECHA y el plan es el mismo, salvando el hecho de que se basa en la tabla del sistema.

Plan
PLAN (TABLA1 ORDER IDX_FECHA2)
PLAN (TABLA1 ORDER IDX_FECHA)
PLAN (RDB$DATABASE NATURAL)

Adapted Plan
PLAN (TABLA1 ORDER IDX_FECHA2) PLAN (TABLA1 ORDER IDX_FECHA) PLAN (RDB$DATABASE NATURAL)

¿Que diferencia hay en cuanto usar la tabla del sistema o la nuestra?

Creo que este hilo no sólo le va a servir a Fernando sino a mi también para aprender

EDITO:

Y si empleo la segunda alternativa, como dices añadiendo el respectivo índice descendiente, llego al mismo plan salvando el hecho de que se basa en los índices para ID:

Plan
PLAN (TABLA1 ORDER IDX_ID2)
PLAN (TABLA1 ORDER PK_TABLA1)
PLAN (RDB$DATABASE NATURAL)

Adapted Plan
PLAN (TABLA1 ORDER IDX_ID2) PLAN (TABLA1 ORDER PK_TABLA1) PLAN (RDB$DATABASE NATURAL)

IDX_ID2 es el índice descendente y PK_TABLA1 el que automáticamente crea el motor.

Saludos,

[Rolphy Reyes]

Saludos.

La ventaja que puedo apreciar entre hacerlo con nuestra tabla y la tabla del sistema, es que el Select es más simple (atacando la tabla del sistema) porque no necesita tanta optimización y como bien indica Marc la tabla del sistema siempre va a devolver un registro.

Sin embargo, nuestra tabla puede devolver más de un registro si no se aplica correctamente la sentencia y se debe de optimizar para evitar el PLAN NATURAL, que es sabido es un Full Scan.

[Marc]

Hola Marc,
He probado la primera opción que mencionas, aprovechando que tengo ya ambos índices en el campo FECHA y el plan es el mismo, salvando el hecho de que se basa en la tabla del sistema.

Plan
PLAN (TABLA1 ORDER IDX_FECHA2)
PLAN (TABLA1 ORDER IDX_FECHA)
PLAN (RDB$DATABASE NATURAL)

Adapted Plan
PLAN (TABLA1 ORDER IDX_FECHA2) PLAN (TABLA1 ORDER IDX_FECHA) PLAN (RDB$DATABASE NATURAL)

¿Que diferencia hay en cuanto usar la tabla del sistema o la nuestra?

En tu tabla tienes que hacer un FIRST 1 para forzarla a que solo devuelva un registro, en cambio utilizando esa tabla de sistema sabes que siempre obtendrás un único registro. Por lo tanto, como dice Rolphy, la consulta es ligeramente más sencilla y por tanto más fácil de leer y comprender.

Utilizar esa tabla es una práctica muy habitual en Firebird para estas situaciones, cuando solo quieres obtener un único registro de datos, y los datos se obtienen de distintas subconsultas o de cualquier otra forma especial.

Por ejplo. para saber la hora en el Servidor Firebird : select current_timestamp from rdb$database

Como ya has visto, el plan generado es el mismo, y es que vas a obtener el mismo resultado que tenías antes, y lo vas a hacer en el mismo tiempo. Solo que en mi opinión la consulta es más simple y fácil de entender a simple vista.

Y si empleo la segunda alternativa, como dices añadiendo el respectivo índice descendiente, llego al mismo plan salvando el hecho de que se basa en los índices para ID:

Plan
PLAN (TABLA1 ORDER IDX_ID2)
PLAN (TABLA1 ORDER PK_TABLA1)
PLAN (RDB$DATABASE NATURAL)

Adapted Plan
PLAN (TABLA1 ORDER IDX_ID2) PLAN (TABLA1 ORDER PK_TABLA1) PLAN (RDB$DATABASE NATURAL)

IDX_ID2 es el índice descendente y PK_TABLA1 el que automáticamente crea el motor.

Si el plan es parecido puesto que esta es la forma más óptima de obtener el resultado, un PLAN NATURAL para el único registro en RDB$DATABASE (como solo hay un registro, no necesitamos ningún índice para llegar a él, es inmediato). Y después un índice para el campo ID ascendente para llegar a su primer registro y otro descendente para llegar inmediatamente al último.

Supongo que ya has notado que en este caso obtienes un resultado distinto al que tienes con la otra consulta.

Imagina que tienes estos datos :

1.- 04/12/2009
2.- 27/12/2009
3.- 14/11/2009
4.- 07/01/2010
5.- 29/01/2010
6.- 24/01/2010
7.- 04/02/2010

En la primera consulta obtienes : Primera -> 14/11/2009, Ultima -> 04/02/2010

En la segunda consulta obtienes : Primera -> 04/12/2009, Ultima -> 04/02/2010

Ahora hay que decidir cual de las dos necesitamos realmente.

Saludos.

[Delphius]

Gracias Marc,
Tengo pendiente aprender sobre las tablas de sistema. Desconozco del tema, y eso hace que me cueste entender apropiadamente las cosas. Sobre todo cuando uno busca mejorar el rendimiento.

Respecto a la diferencias entre ambas consultas la entiendo. No necesariamente van a dar el mismo resultado y es por ello que señalé a pcicom que no necesariamente Min() y Max() sea la solución correcta.

Enecúmene dijo primero y último y es por ello mi duda...

Saludos,

[pcicom]

¿Seguro que esa consulta funciona? La he probado y me indica que hay un error justo en el select después de ese paréntesis.

Claro solo con mis BD y mis campos...  habria que probarlos con los tuyos..

pcicom la consulta que muestras podría llegar a ser válida en el eventual caso en que tanto Min() como Max() coincidan con el primer y último registro. Min() no devuelve el primer registro, sólo el mínimo y Max() no regresa el último sino el máximo.
Puedes estar ubicados en cualquier ubicación.
Es sólo coincidencias y una casualidad de que se dieran casos en los que Min() = primero y Max() = último. Nada impide que el mínimo y/o el máximo estén en el medio.

Creo que bajo la logica en la cual se intenta saber cual es la primer fecha capturada en el sistema se puede utilizar la funcion interna MIN(?)  y saber la ultima fecha con MAX(?)...

Imagina que tienes estos datos :

1.- 04/12/2009
2.- 27/12/2009
3.- 14/11/2009
4.- 07/01/2010
5.- 29/01/2010
6.- 24/01/2010
7.- 04/02/2010
8.- 01/02/2010

El Min regresaria la fecha inidcada como numero (3)
El Max regresaria la fecha indicada como la (7)

En el sentido de querer la fecha del primer registro y la del ultimo registro, a mi entender no me serviria de mucho, salvo conocer la secuencia de captura en cuyo caso no requeririas indices..

Creo que enecumene nos debera de indicar si efectivamente lo que busca es el primer y ultimo registro o los valores de la primer fecha menor y la ultima fecha =mayor...

Aparecete ENECUMENE..    jejejejej    ILUMINANOS..






La ordenación de los registros depende de los índices activos y es sólo a efectos visuales. Internamente se podría decir que los datos son almacenados siguiendo una estructura árbol, luego estos al momento de mostrarse reciben la forma tabular (que tan acostumbrados estamos a ver... quizá por ello es tan fácil asumir que los datos son guardados secuencialmente) y el orden de cada registro dependerá de los índices.

Pues si, los indices son muy importantes al realizarse busquedas indudablemente

La consulta que yo he colocado debe refinarse para adaptarse del mejor modo posible a las necesidades y usos. Por ello si bien canté victoria en su momento aclaré que necesita evaluarse si es realmente lo que se busca. Sobre todo si existen otras posibles operaciones sobre la tabla y que requieren un tratamiento basado en otros campos.

Definitivamente siempre habra distintas formas de llegar a ROMA...

Saludos, Igualmente...

[Marc]

Tengo pendiente aprender sobre las tablas de sistema. Desconozco del tema, y eso hace que me cueste entender apropiadamente las cosas. Sobre todo cuando uno busca mejorar el rendimiento.

No te preocupes mucho por las tablas de sistema. Solo se utilizan cuando necesitas consultar datos del sistema, como : lista de tablas, o bien : lista de campos para una determinada tabla. En caso de que necesites algo de este estilo, solo tienes que preguntarlo, pero no es común.

En cambio la rdb$database es la única que se utiliza con algo de frecuencia en un uso normal, puesto que se ha cogido este convenio de usarla para las consultas que solo tienen que devolver un registro.

Saludos.

[enecumene]

Vaya que con éste hilo sí que he aprendido cosas nuevas de Firebird . Gracias a todos.

[Delphius]

¡Hola!

Gracias Marc por las aclaraciones. Quizá no sea algo urgente pero si... algo de eso tendré que estudiar, aunque sea poco y superficial.

Fernando, no eres el único que ha aprendido nuevas cosas , yo también me llevo algo nuevo hoy . A este hilo lo voy a tener que guardar en mi biblioteca e imprimirlo... ya tengo que empezar mi biblioteca DelphiAccess... ya hay mucho material con el que puedo trabajar.

Saludos,