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

[[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 Noteví]

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

[[poliburro]]

Empezado por Casimiro Notevi

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

¿y a que viene eso? estoy diciendo algo errado? honestamente no conozco suficiente firebird por eso pregunto.

[Casimiro Noteví]

Precisamente, amigo, es que me extraña muchísimo tu actitud, cualquier cosa que se comente es suficiente para que digas algo como: "pero firebird no tiene talcosa ", "pero firebird no tiene laotracosa ", etc.

Yo no veo en ningún sitio que se haya dicho nada sobre los planes de ejecución, que por supuesto que tiene, y la interpretación que estás haciendo de los "stored procedure" también le buscas el lado malo: "tanto código hay que escribir para esto o para aquello ".
Cuando realmente es que no lo has entendido, o no se te ha explicado bien.

[[poliburro]]

Empezado por Casimiro Notevi

Precisamente, amigo, es que me extraña muchísimo tu actitud, cualquier cosa que se comente es suficiente para que digas algo como: "pero firebird no tiene talcosa ", "pero firebird no tiene laotracosa ", etc.

Empezado por Casimiro Notevi

Precisamente, amigo, es que me extraña muchísimo tu actitud, cualquier cosa que se comente es suficiente para que digas algo como: "pero firebird no tiene talcosa ", "pero firebird no tiene laotracosa ", etc.

Pues creo que no me estas leyendo correctamente amigo mio... Acaso no ves el signo "?" al final de mis oraciones?

Es una pregunta la que hago. Acaso preguntar algo es un desvario?

Empezado por poliburro

En Firebird debes hacer todo ese código para poder dar salida a un simple resultset en un SP?

[cointec]

Hola poliburro, lo que no entiendo es la frase "tienes que hacer todo ese código para devolver un resulset", cuando lo único que se tiene que escribir en el cuerpo del procedimiento almacenado si deseas devolverlo como resultset es "suspend"

El resto de código es común y la lógica será la misma que en cualquier motor.

Por otro lado, cuando te pedía el ejemplo no era en la llamada al procedimiento, sino en que escribieses el cuerpo del procedimiento en sqlserver, mysql, etc. para poder comprobar a lo que te referias con "todo ese código".

Imagino que en los motores que comentas, tendrás que declarar la estructura del resultset, con campos y tipos, que es equivalente a los parámetros de retorno del procedimiento almacenado. Dentro del procedimiento, tendrás que introducir los datos en variables e insertarlos en el resultset, para poder posteriormente devolverlos y por último devolver una referencia al resultset. Desde tu aplicación cliente tendrás una llamada al procedimiento almacenado y posteriormente otra llamada para obtener los datos insertados en el resultset.

En firebird, la sencillez es que la llamada al procedimiento ya es un resultset. Quizá con ejemplos sería mejor, por lo que sí nos pones algún ejemplo en otros motores, te podríamos mostrar su traducción a firebird y podríamos comparar cosas y no utilizar frases genéricas que creo no tienen sentido.

[[mightydragonlor]]

Empezado por cointec

Hola poliburro, lo que no entiendo es la frase "tienes que hacer todo ese código para devolver un resulset", cuando lo único que se tiene que escribir en el cuerpo del procedimiento almacenado si deseas devolverlo como resultset es "suspend"

El resto de código es común y la lógica será la misma que en cualquier motor.

Por otro lado, cuando te pedía el ejemplo no era en la llamada al procedimiento, sino en que escribieses el cuerpo del procedimiento en sqlserver, mysql, etc. para poder comprobar a lo que te referias con "todo ese código".

Imagino que en los motores que comentas, tendrás que declarar la estructura del resultset, con campos y tipos, que es equivalente a los parámetros de retorno del procedimiento almacenado. Dentro del procedimiento, tendrás que introducir los datos en variables e insertarlos en el resultset, para poder posteriormente devolverlos y por último devolver una referencia al resultset. Desde tu aplicación cliente tendrás una llamada al procedimiento almacenado y posteriormente otra llamada para obtener los datos insertados en el resultset.

En firebird, la sencillez es que la llamada al procedimiento ya es un resultset. Quizá con ejemplos sería mejor, por lo que sí nos pones algún ejemplo en otros motores, te podríamos mostrar su traducción a firebird y podríamos comparar cosas y no utilizar frases genéricas que creo no tienen sentido.

En MsSql no necesitas declarar los resulsets de salida, sólo con que tengas varios Select * from tabla serán retornados sin problemas, para el caso de oracle se declaran cursores de salida, y los llenas con sus respectivos Select, cada uno deberá ser declarado para que pueda ser retornado, para el caso del actual firebird sólo devuelve un resulset con un select y un suspend, en Oracle es casi igual ya que sólo se devuelve por cada cursor que se llena, pero en MsSQL la cosa cambia, ya que no puedes usar los Select "libremente" hay que tener cuidado de no devolver lo que no se desea, pero para este caso se usa IF EXISTS(SELECT * FROM TABLA) o también puedes usar un SET @Variable = (SELECT * FROM TABLA) y con esto se evitar devilver lo que no se requiere.
PD: Si no estoy mal, para la versión 3 de Firebird que no está lejos de salir, se va a soportar la salida de varios cursores o resulsets en un procedimiento almacenado y en execute block, creo que también en funciones.

Saludos.

[[Al González]]

Me parece que Casimiro ha detectado el tono con el que haces esas preguntas, Edgar, que no es precisamente el de alguien que espera recibir una respuesta didáctica y amable. Dices que no conoces lo suficientemente Firebird, pero recalcas las limitaciones que a tu juicio tiene. Respondes con efugios a algunas de las observaciones que de buena fe te hacen algunos de los compañeros en un intento por hacerte entrar en razón, para luego hacer comparaciones tendenciosas.

A los que hemos seguido este hilo ya nos quedó claro que guardas una especie de inquina hacia Firebird. Yo desconocía esto de ti (o mi memoria es mala), y de haberlo sabido antes no hubiera puesto en el mismo mensaje la pregunta inicial y la referencia a tu artículo. Ahora, en lo personal creo que las consultas de múltiples cursores es algo que Firebird debiera tener.

Algo ha de rescatarse de este mal devenido debate.

Saludos.

[roman]

Empezado por Al González

Algo ha de rescatarse de este mal devenido debate.

A lo que yo he contribuido. Lo lamento.

--------

Aunque no es exactamente pra rescatar el debate, pues más bien es una duda, me gustaría, Al, leer tu opinión de porqué es buena esta característica de los múltiples result sets.

El ejemplo de poliburro no me aclara pues, a mi juicio, es algo que puede lograrse con enlaces entre tablas para recabar la información deseada. ¿Tendrías alguna situación en mente en la qué aplicar dicha técnica?

// Saludos

[[poliburro]]

Empezado por Al González

A los que hemos seguido este hilo ya nos quedó claro que guardas una especie de inquina hacia Firebird. Yo desconocía esto de ti (o mi memoria es mala), y de haberlo sabido antes no hubiera puesto en el mismo mensaje la pregunta inicial y la referencia a tu artículo. Ahora, en lo personal creo que las consultas de múltiples cursores es algo que Firebird debiera tener.

1.- Por allí anda un botón que se llama editar amigo.. puedes eliminar la referencia a mi artículo cuándo lo consideres correcto y de esa manera evitarte lamentaciones.

2- No tengo ningún tipo de "inquina" contra firebird. No aprecio a ese motor de base de datos y tampoco soy muy dado a elegirlo para mis proyectos. Pero si fuera contratado para trabajar en él lo haría sin ningún problema.

3- He visto aquí a muchos vosciferar contra Windows, .Net, Vb, Sql Server, la iglesia, el anticristo, etc etc y no ha habido ningún problema en ello. ¿Por qué se considera tan "mala" mi "inquina" contra Firebird?

[[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

[[mightydragonlor]]

Bueno, este documento explica un poco sobre los procedimientos almacenados, es viejo y trata de Interbase, pero para este caso, acplica, este otro es algo mas actual y muestra mas cosas.

Saludos.