¿Firebird soporta consultas que devuelven más de un cursor ("record set")?

[[poliburro]]

Empezado por mightydragonlor

Dentro de un procedimiento almacenado e incluso en un EXECUTE BLOCK puedes tener varios SELECT, pero el select que retorna los datos es el que tiene el SUSPEND, creo que lo mismo aplica en variables de salida, que a la final es lo mismo.

Saludos.

Entonces entiendo que el suspend identifica de manera explicita que select quieres devolver... lo cual no debería ser necesario peus el mismo lenguaje PLSQL o TSQL establece la manera en que un sp retorna un recordset...

supongo que debe tener algún uso adicional en firebird... o es solo ese? identificar que selecte se devolvera?

[[RONPABLO]]

Empezado por poliburro

Entonces entiendo que el suspend identifica de manera explicita que select quieres devolver... lo cual no debería ser necesario peus el mismo lenguaje PLSQL o TSQL establece la manera en que un sp retorna un recordset...

supongo que debe tener algún uso adicional en firebird... o es solo ese? identificar que selecte se devolvera?

El suspend se usa para procedimientos almacenados que retornan un Dataset con varias columnas y varios registros, como tal es la orden de mandar la información en el momento que usted quiera, así pues uno hace el

Código SQL [-]
select campo1, campo2 from  tabla

Y no por eso se va a retornar los datos de campo1 y campo2 como resultados de un cursor, en Firebird tengo que declarar que parametros van a salir en el cursor e ir por medio de un comando llamado "for select" recorriendo el dataset que necesito consultar, ahora yo con la información que me retorna Campo1, Campo2 en el "for select " no necesariamente es la que quiero mostrar, con ella por ejemplo necesito hacer varias operaciones antes de mostrarla y al final puedo entregar un recordSet construido con información muy diferente a la que viene en la consulta original y es ahí cuando tengo el resultado que igual en una o varias variables de resultado y doy la orden de suspend y me sale un recordset con campo3 y campo4 que eran los resultados obtenidos por campo1 y campo2,

también puedo fabricar un recordset de algo que no es una tabla, ejemplo

Código SQL [-]
SET TERM ^^ ;
CREATE PROCEDURE SP_CADENA_A_RECORD (
  AINPUT VarChar(8192))
 returns (
  VALOR Integer)
AS
declare variable LASTPOS integer;
declare variable NEXTPOS integer;
begin
  AINPUT = :AINPUT || ',';
  LASTPOS = 1;
  NEXTPOS = position(',', :AINPUT, LASTPOS);
  while (:NEXTPOS > 1) do
  begin
    valor = cast(substring(:AINPUT from :LASTPOS for :NEXTPOS - :LASTPOS) as integer);
    LASTPOS = :NEXTPOS + 1;
    NEXTPOS = position(',', :AINPUT, LASTPOS);   
    suspend;
  end
  
end ^^
SET TERM ; ^^

Con el procedimiento almacenado anrterio envio como paramentro de entrada una seríe de números separados por comas, por decir "1,4,6,7,12,22", internamente hago una operación de cadenas y retorno como recortset los números en valor entero, y con ellos puedo hacer inner joins on validaciones tipo exists que me funcionan más rápido que validaciones "where campo in ('1,4,6,7,12,22').


la verdad siento que no soy muy claro al tratar de explicarme, pero eso es una idea de lo que hace el suspend

[[poliburro]]

Empezado por RONPABLO

El suspend se usa para procedimientos almacenados que retornan un Dataset con varias columnas y varios registros, como tal es la orden de mandar la información en el momento que usted quiera, así pues uno hace el

Código SQL [-]select campo1, campo2 from tabla


Y no por eso se va a retornar los datos de campo1 y campo2 como resultados de un cursor, en Firebird tengo que declarar que parametros van a salir en el cursor e ir por medio de un comando llamado "for select"

Pero eso no es agregar código adicional? Mysql y MsSql por ejemplo tu haces un

Código SQL [-]
 
   Select Campo1,Campo2,..,CampoN
     from tabla 
    where  criterio = ValParam1 or
              criterio = valParam2

y eso obtienes al ejecutr el SP con lo que no requieres de un suspend o fetch etc...

En oracle y Db2 al contrario debes delcarar como un cursor el recordset que deseas dar como salida del SP pero al final con un mero Open CurName obtienes la salida del sp...

Entonces.. déjame ver si entiendo bien, En Firebird debes hacer todo ese código para poder dar salida a un simple resultset en un SP?

[cointec]

Empezado por poliburro

Pero eso no es agregar código adicional? Mysql y MsSql por ejemplo tu haces un

Código SQL [-]
 
   Select Campo1,Campo2,..,CampoN
     from tabla 
    where  criterio = ValParam1 or
              criterio = valParam2

y eso obtienes al ejecutr el SP con lo que no requieres de un suspend o fetch etc...

En oracle y Db2 al contrario debes delcarar como un cursor el recordset que deseas dar como salida del SP pero al final con un mero Open CurName obtienes la salida del sp...

Entonces.. déjame ver si entiendo bien, En Firebird debes hacer todo ese código para poder dar salida a un simple resultset en un SP?

Hola, creo que uno de las mayores virtudes que creo no tienen otros motores es que se puede tratar un procedimiento almacenado como una tabla virtual y trabajar con ellos conforme si lo fuesen. El ejemplo que se ha puesto es muy simple y habría que ver como se hace un proceso complejo en otros motores para poder valorar si se necesita o no más código.

No es lo mismo devolver un cursor, que el propio procedimiento sea un cursor.

Select *
From procedimiento( aram1, aram2,..., : paramN )

Un procedimiento no se realiza para sustituir un simple select como en el caso que has puesto, su objetivo es realizar un procesamiento más o menos complejo, donde pueden intervenir consultas de varias tablas y operaciones más o menos complejas con los datos obtenidos de ellas, por ejemplo. Una de sus funciones es no es sustituir un simple select. Y el resultado de todo ello es un conjunto de registros que puedes tratar como una tabla.

Quizá podrías mostrar como devolver un recordset con características similares en sqlserver, mysql u oracle para poder comparar realmente si es más o menos complejo, porque no creo que se pueda comparar el select que has puesto como ejemplo con el procedimiento almacenado que se ha escrito.

[[poliburro]]

Empezado por cointec

No es lo mismo devolver un cursor, que el propio procedimiento sea un cursor.

Select *
From procedimiento( aram1, aram2,..., : paramN )

Un procedimiento no se realiza para sustituir un simple select como en el caso que has puesto, su objetivo es realizar un procesamiento más o menos complejo, donde pueden intervenir consultas de varias tablas y operaciones más o menos complejas con los datos obtenidos de ellas, por ejemplo. Una de sus funciones es no es sustituir un simple select. Y el resultado de todo ello es un conjunto de registros que puedes tratar como una tabla.

Quizá podrías mostrar como devolver un recordset con características similares en sqlserver, mysql u oracle para poder comparar realmente si es más o menos complejo, porque no creo que se pueda comparar el select que has puesto como ejemplo con el procedimiento almacenado que se ha escrito.

Claro, un SP contiene dentro de si mucho código PLSQL, pero en el caso que se trata es meramente sobre como devolver un resulset. y si, aunque parezca muy simple, realmente en otros motores de bases de datos devolverlos es muy sencillo... no necesitas tanto trabajo para devolver un simple resultset.

esto

Código SQL [-]
 
Select * 
From procedimiento( aram1, aram2,..., : paramN )

Es exactamente lo mismo que cualquiera de estos:

Código SQL [-]
 
CALL procedimiento( param1, param2,..., : paramN );
 
Exec procedimiento( param1, param2,..., : paramN );

Te devuelven todos un resulset

[[RONPABLO]]

Empezado por poliburro

Claro, un SP contiene dentro de si mucho código PLSQL, pero en el caso que se trata es meramente sobre como devolver un resulset. y si, aunque parezca muy simple, realmente en otros motores de bases de datos devolverlos es muy sencillo... no necesitas tanto trabajo para devolver un simple resultset.

esto

Código SQL [-] Select * From procedimiento( : Param1, : Param2,..., : paramN )


Es exactamente lo mismo que cualquiera de estos:

Código SQL [-] CALL procedimiento( param1, param2,..., : paramN ); Exec procedimiento( param1, param2,..., : paramN );


Te devuelven todos un resulset

No, no lo es, el SP en firebird tiene tratamiento muy similar a una tabla y con él le puedo hacer Joins, o puedo hacer un Insrt into table from select * from SP_proceso_antes_de_insertar cosa que con los CALL "SP" o Exec "SP" no se puede hacer

[[RONPABLO]]

Código SQL [-]
   Select Campo1,Campo2,..,CampoN      from tabla      where  criterio = ValParam1 or               criterio = valParam2

En Sql Server es muy común ver procedimientos con una simple consulta ya que mejoran la velocidad de la consulta (tengo entendido), así pues es más rápido consultar información de una tabla por medio de un procedimiento almacenado que por una consulta directa en un componente similar al TQuery, en firebird por el contrario esto no cambia mucho y no se acostumbra a tener un procedimientos para insertar, otro para modificar y otro para consultar (no por lo menos para hacer estos procesos más rápidos), con firebird se construyen un Dataset muy fácilmente sin la necesidad de consultar una tabla como es el caso del ejemplo que envié en el procedimiento llamado SP_CADENA_A_RECORD, ese procedimiento no consulta sobre ninguna tabla, solo va procesando una cadena y va retornando un DataSet, lo consulto en un IBQuery haciendo un:

Código SQL [-]
 select valor from SP_CADENA_A_RECORD('1,3,4,6,8,12')

Por ejemplo le puedo hacer un join con una tabla

Código SQL [-]
 select valor from SP_CADENA_A_RECORD('1,3,4,6,8,12') as CR inner join MovimientosPorOficina as MPO on CR.Valor = MPO.Idbodige

[[poliburro]]

Empezado por RONPABLO

En Sql Server es muy común ver procedimientos con una simple consulta ya que mejoran la velocidad de la consulta (tengo entendido),

No necesariamente un SP puede tener una consulta... puede contener múltiples consultas al igual que ORACLE, DB2, MYSQL, POSTGRESQL, etc

Sobre el rendimiento de la consulta en un SP, esto aplica para la gran mayoria de motores de bases que cuentan con algo llamado "Execution plan" Acaso firebid no lo tiene? Cómo hace firebird para decidir la ruta más óptima para ejecutar una sentencia sql?

Cómo hacen ustedes para verificar en Firebrid que no están ejecutando un "Table Scan" al ejecutar una consulta?

¿Firebird es capaz de permitirles decidir como y cuándo usar determinados índices en una tabla?

Empezado por RONPABLO

con firebird se construyen un Dataset muy fácilmente sin la necesidad de consultar una tabla como es el caso del ejemplo que envié en el procedimiento llamado SP_CADENA_A_RECORD,

Pues con Mysql, Oracle, Db2, MsSql hacer eso es aún más sencillo:

Código SQL [-]
select *  from (Select 'Data' As Dummyfield) TableDummyInner join Table      on 1 = 1

[Casimiro Notevi]

Amigo Poliburro, ¡¡¡qué manera de desvariar!!!, lo tuyo con firebird es grave

[[RONPABLO]]

Empezado por poliburro

No necesariamente un SP puede tener una consulta... puede contener múltiples consultas al igual que ORACLE, DB2, MYSQL, POSTGRESQL, etc

Firebird también puede tener varias consultas.

Empezado por poliburro

Sobre el rendimiento de la consulta en un SP, esto aplica para la gran mayoria de motores de bases que cuentan con algo llamado "Execution plan" Acaso firebid no lo tiene? Cómo hace firebird para decidir la ruta más óptima para ejecutar una sentencia sql?

Ejecutando el plan, pero lo puedo hacer directamente desde la consulta sin pasar por un SP, aun así en el SP también puedo ejecutar el plan, tiene herramientas para analizar el rendimiento al ejecutar con un plan o con el otro

Empezado por poliburro

Cómo hacen ustedes para verificar en Firebrid que no están ejecutando un "Table Scan" al ejecutar una consulta?

hay herramientas de estadística que nos muestra si una consulta está o no usando indice, los tiempos que se demoran al hacer una consulta, cual es el plan usado, etc

Empezado por poliburro

¿Firebird es capaz de permitirles decidir como y cuándo usar determinados índices en una tabla?

Sí.

Empezado por poliburro

Pues con Mysql, Oracle, Db2, MsSql hacer eso es aún más sencillo:

Código SQL [-]

select * from (Select 'Data' As Dummyfield) TableDummyInner join Table on 1 = 1

No es lo mismo, estoy hablando que en Firebird se puede hacer uniones, consultas y subconsultas a un procedimiento almacenado (se puede tomar como si fuera un view de SQL Server pero con la potencia que da los procedimientos almacenados), cosa que no se puede hacer en SQL Server, ahora, no entiendo que resultado traerá el ejemplo que pones en tu ejemplo, para ser más claro en el procedimiento almacenado que puse de ejemplo al hacer una consulta como:

Código SQL [-]
select valor from SP_CADENA_A_RECORD('1,3,4,6,8,12')

el resultado va ser un DataSet:

Valor
1
3
4
6
8
12

Al cual le puedo hacer una subconsulta, o hacer join, o lo puedo llamar en otro Procedimiento almacenado:

Código SQL [-]
   for select valor from SP_CADENA_A_RECORD('1,3,4,6,8,12') order valor into :Valor do
   begin
      for Select c.Nombre, c.Encargado, CXC.Fecha, CXC.Cupos 
      from Ciudades c 
      inner Join CalendarioXCiudad CXC on c.Id = CXC.IdCIudad
      where C.Id = :Valor into :Ciudad, :Encargado, :FechaEvento, :Cupos do
      begin
         suspend;
      end
   end