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

Al González

08-11-2012, 20:34:35

Leyendo este artículo (http://elpoli.delphiaccess.com/gestionar-multiples-datasets-con-ado-y-delphi/) de nuestro compañero poliburro (http://www.clubdelphi.com/foros/member.php?u=3694) (recomiendo su recién iniciado blog), supe que MS SQL Server soporta consultas que regresan más de un cursor o record sets. No me extraña de ese motor, dada su fama de añadir cuanta cosa Microsoft considera útil sin consensuarlo con la industria.

La característica me parece buena y, como no estoy actualizado en Firebird, desconozco si éste último posee ya algo similar o lo proyecta tener. De ahí el título de este hilo. Llama la atención que tanto PostgreSQL como MySQL sí cuenten con esa característica, según se menciona ahí.

La intención no es generar polémicas (aunque sé que será inevitable :D). Sino conocer un poco más sobre esto y sacar a la luz lo que a Firebird concierna (presente o futuro).

Saludos múltiples.

Casimiro Notevi

08-11-2012, 20:59:25

Nunca había oido sobre esa característica.
He hecho una búsqueda por google y no he encontrado nada al respecto.
:confused:

poliburro

08-11-2012, 21:17:38

Leyendo este artículo (http://elpoli.delphiaccess.com/gestionar-multiples-datasets-con-ado-y-delphi/) de nuestro compañero poliburro (http://www.clubdelphi.com/foros/member.php?u=3694) (recomiendo su recién iniciado blog), supe que MS SQL Server soporta consultas que regresan más de un cursor o record sets. No me extraña de ese motor, dada su fama de añadir cuanta cosa Microsoft considera útil sin consensuarlo con la industria.

Saludos Al, como te respondí en mi blog, esta es una característica presente en Oracle, Sql Server, Mysql, Db2 y PostgreSql. Hablo de esos motores pues son los que más uso y dónde he probado el retorno de múltiples recordsets.

No se si lo soporte Firebird, supongo que sería algo más por agregar a la larga lista de "cosas" que no soporta.

Saludox

Edito. :) Gracias por la recomendación...

Casimiro Notevi

08-11-2012, 21:28:27

No se si lo soporte Firebird, supongo que sería algo más por agregar a la larga lista de "cosas" que no soporta.

¿Y cuál es esa larga lista? :confused:

poliburro

08-11-2012, 21:33:15

Algunas serían:

Soporte XML
Soporte para XML SCHEMA
Soporte ETL
Soporte de conectividad entre pares
Soporte de conectividad entre diferentes
Visibilidad entre diferentes esquemas del mismo servidor

poliburro

08-11-2012, 21:34:27

Por cierto... no me gusta la idea de debatir sobre si es bueno o no Firebird. si a ustedes les gusta me parece bien. A mi en lo personal no me gusta ese motor de base de datos.

Casimiro Notevi

08-11-2012, 22:02:45

Hombre, has empezado tú ;)

Casimiro Notevi

08-11-2012, 22:07:02

Algunas serían:

Soporte XML
Soporte para XML SCHEMA
Soporte ETL
Soporte de conectividad entre pares
Soporte de conectividad entre diferentes
Visibilidad entre diferentes esquemas del mismo servidor

Existen utilidades de terceros para XML y también ETL.
Lo de conectividad entre pares y diferentes... no tengo ni idea de qué es, ni para lo que sirve :confused:

Y ya puestos, yo considero a firebird, postgresql y mysql... muchísimo mejor que MS sql server, ya que las primeras se ejecutan en diferentes sistemas operativos, por lo que pueden funcionar desde pequeños ordenadores hasta los mayores mainframes existentes.
Sin embargo MS sql server sólo funciona sobre un simple y 'doméstico' PC con S.O. windows :D

movorack

08-11-2012, 22:40:30

Hace un tiempo conocí PostgreSQL y dejé de usar firebird. Pero si hay muchas cosas de este rdbms que vienen muy de la mano con delphi (Recordar que firebird viene de interbase un producto nacido en inprise y muy cercano a borland) y lo que me gustó de PostgreSQL era la posibilidad de utilizar el mismo motor en PHP y Delphi de una manera muy transparente.

Pero hace ya casi dos años logré trabajar MS-SQL de la mano de la empresa donde trabajé hasta hace muy poco. y me dí cuenta que en entornos empresariales, la batalla MS-SQL vs Mysql/PostgreSQL/Firebird la gana siempre MS-SQL y no solamente por ser Microsoft sino por su seguridad, la facilidad de administración, tareas integradas con las tareas del windows server, integración con active directory y además que montado en un buen servidor ofrece muy buenos rendimientos.

Dificilmente veo a Firebird/Mysql (Open Source)/PostgreSQL (Usa Kerberos) totalmente integrados (o por lo menos de forma nativa al rdbms) en una empresa cuya infraestructura de red se base en un Active Directory y requieran que los usuarios del dominio ingresen con su propio usuario (del dominio) y contraseña al aplicativo.

¿El hecho de que MS sql server funcione desde un simple y 'domestico' PC con S.O. windows no debería ser una ventaja mas que una desventaja?
¿No es ese uno de los puntos claves de Firebird y otros que pueden funcionar en equipos que van desde pc hasta grandes servidores o clusteres?
¿El hecho de que solo funcione en Windows es en realidad una desventaja cuando logras una grán integración con el S.O. y los demás servicios del mismo y que además cuando está sobre Windows Server ofrece muchas ventajas para los administradores de recursos de red?

No es una defensa o venir a decir que uno es malo u otro es bueno. Solo que no podemos comportarnos tipo fanboy con su smartphone (sea cual sea) y demonizar cualquier critica sea sana o no.

Aquí les dejo un link de comparaciones de estas y algunas otras bases de datos (http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems)

poliburro

08-11-2012, 22:48:15

Existen utilidades de terceros para XML y también ETL.
Lo de conectividad entre pares y diferentes... no tengo ni idea de qué es, ni para lo que sirve :confused:

¿y qué utilidades son? Me gusta mucho trabajar en bases de datos y firebird no me ha convencido por la falta de ese soporte. Sería un aliciente para mi el conocer sobre esas herramientas de terceros.

La conectividad entre múltiples servidores de bases de base de datos te permiten implementar soluciones nativas para replicación de información. O para la consulta entre diferenets orígenes de datos: Algo como

Select Servidor1.Data, Servidor2.Data
from servidor1.schema.table1 tserv1
left join servidor2.schema.table1 tserv2
on tserv1.keyfield = tserv2.keyfield

es sumamente útil. Al igual el poder hacer consultas entre diferentes esquemas del motor de base de datos. O poder hacer consultas de manera directa a servidores de diferente vendedor.

Sobre que MsSql no corre en otros OS, eso es cierto pero para ello tienes alternativas como Oracle, Db2 o PotgreSql. Yo jamás eligiría Firebird ni para windows o linux.

Sobre que MsSql solo corre en pcs domésticas, bueno allí que te puedo decir, me parece más una opinión al aire para denostar algo que se desconoce.

Ojo, Soy un gran fan de los motores de bases de datos en general. Me gusta mucho trabajar en ellos, en su administración, en su optimización así que no defiendo a uno en particular y si a todos en general.

Saludos

Y bueno a todo esto.... firebird soporta devolver mútiples resultsets?

poliburro

08-11-2012, 22:50:59

No es una defensa o venir a decir que uno es malo u otro es bueno. Solo que no podemos comportarnos tipo fanboy con su smartphone (sea cual sea) y demonizar cualquier critica sea sana o no.

Total y absolutamente de acuerdo amigo movorack.

¿Por cierto, has probado la integración de fedora directory para entornos empresariales con distribuciones basadas en RedHat? Podría ser una manera de consolidar tus entornos de trabajo en ese sistema operativo.

Kipow

08-11-2012, 22:57:42

Hasta donde se Firebird no lo soporta. Pero prefiero generar procedimientos independientes para cada consulta para el mejor manejo de hilos y conexiones al servidor

Casimiro Notevi

08-11-2012, 23:05:55

y lo que me gustó de PostgreSQL era la posibilidad de utilizar el mismo motor en PHP y Delphi de una manera muy transparente.
Y con firebird también, lo he usado hasta yo mismo.

gana siempre MS-SQL y no solamente por ser Microsoft sino por su seguridad, la facilidad de administración, tareas integradas con las tareas del windows server, integración con active directory y además que montado en un buen servidor ofrece muy buenos rendimientos.
No puedes ni compararlo, ¿seguridad?, ¿facilidad de administración?, ¿buenos rendimientos?... con firebird...
Seguridad, después de 14 años de uso: cero fallos.
Facilidad de administración: No puedes compararlo de ninguna manera, firebird lo instalas en 30 segundos en cualquier equipo y no tienes que tocar nada. Más facilidad de administración es imposible.
Rendimiento: En todos estos años son centenares de clientes a los que hemos sustituido ms sql+windows por firebird+linux y lo primero que dicen es: ¡¡¡¡qué rapidez!!!

¿El hecho de que MS sql server funcione desde un simple y 'domestico' PC con S.O. windows no debería ser una ventaja mas que una desventaja?
No, yo no he dicho "desde", he dicho "solamente", ms sql sólo funciona en windows. Punto.

¿No es ese uno de los puntos claves de Firebird y otros que pueden funcionar en equipos que van desde pc hasta grandes servidores o clusteres?
Exacto, cosa que no puede hacer ms sql, que sólo funciona en windows.

¿El hecho de que solo funcione en Windows es en realidad una desventaja cuando logras una grán integración con el S.O. y los demás servicios del mismo y que además cuando está sobre Windows Server ofrece muchas ventajas para los administradores de recursos de red?
Sí, desde luego, es una desventaja que sólo funcione en windows.

No es una defensa o venir a decir que uno es malo u otro es bueno. Solo que no podemos comportarnos tipo fanboy con su smartphone (sea cual sea) y demonizar cualquier critica sea sana o no.
Son sólo realidades, incluso postgresql (con su fama de lento) es más rápido que ms sql server.

Cada uno tiene sus gustos, simplemente, y para mí, un RDBMS que sólo funciona en windows ya lo descartaría antes incluso de entrar en una lista para evaluarlo.
No me parece serio ni profesional un servidor empresarial con windows.
Y ya no hablemos de pagos de licencias del servidor, del sistema operativo, del RDMBS, del antivirus :eek: y de todas esas chorradas que lleva aparejadas windows.

Será que he usado unix y linux (en 1988 ya instalaba unix en las empresas) que windows me parece una atracción de feria.

¡¡¡Venga, debate!!! :D

poliburro

08-11-2012, 23:09:39

Rendimiento: En todos estos años son centenares de clientes a los que hemos sustituido ms sql+windows por firebird+linux y lo primero que dicen es: ¡¡¡¡qué rapidez!!!

Eso depende siempre del diseñador de la base de datos y su administrador. Vieras que me han dicho lo mismo en algunos sistemas que he remplazado donde quité a un firebird lentisimo.... y lo he sustituido por otro motor.

poliburro

08-11-2012, 23:10:32

Casimiro Notevi

08-11-2012, 23:14:32

¿y esto lo basas en?

Aquí (http://intitec.com/varios/bmsql-postgres-sqlsrvr-v1.0-1.pdf) lo tienes :)

poliburro

08-11-2012, 23:20:02

Aquí (http://intitec.com/varios/bmsql-postgres-sqlsrvr-v1.0-1.pdf) lo tienes :)
y lo has hecho alguna vez? o Has googleado buscando esa comparatva sin haber conseguido jamás un rendimiento mayor?

Por que te diré al menos yo si lo he comprobado y que de ahí se que es verdad. Hasta antes de sql server 2012 PostgreSql era capaz de obtener mejores tiempos de procesamiento y respuesta. Conseguirlo era muy sencillo, tan solo separabas los índices y lo colocabas en un arreglo de discos de alta velocidad y buala¡¡¡¡¡¡¡ mejora instantánea....

ojo... y no necesité remitirte a un docuemento que seguramente no has leido a cabalidad ni implementado siquiera... :)

Casimiro Notevi

08-11-2012, 23:27:23

Hombre, amigo Poliburro, ahí has soltado unas frases que se las trae :confused:

No voy a ser yo quien te aclare lo que has dicho, pero vuelve a leer lo que has escrito, imagina que ha sido otra persona.
Es que no puedo creer que hayas sido tú :confused::confused::confused:

Sin comentarios.

Al González

08-11-2012, 23:33:17

Nunca había oido sobre esa característica.
He hecho una búsqueda por google y no he encontrado nada al respecto.
:confused:
Hasta donde se Firebird no lo soporta. Pero prefiero generar procedimientos independientes para cada consulta para el mejor manejo de hilos y conexiones al servidor
Creo que con esto se satisface mi duda, y supongo que no hay planes (que se sepa) de añadir esa útil característica.

En mi caso particular, no me parece algo de peso para dejar de usar Firebird en proyectos poco ambiciosos, como en los que habitualmente trabajo. He tenido la fortuna de usar un poco MS SQL Server, pero me siento más cómodo con Firebird por su sencillez de manejo y por lo bien que parece entenderse con Delphi. Claro que si llego a necesitar características que Firebird no tenga, habré de estudiar qué otro motor convendría usar, considerando ventajas y desventajas, cual debe ser ante cada problema que se le presenta a un desarrollador.

Y por supuesto que, ya estando en MS SQL Server, no desaprovecharía esa útil característica que poliburro explica bastante bien. :)

Un abrazo cortafuegos.

Al González.

movorack

08-11-2012, 23:48:49

No... la verdad no soporta esa característica y eso está detectado desde hace mucho tiempo.

Support stored procedure returning mutliple dataset
Created: 30/Mar/07 04:50 PM
As a MS SQL user, one of the most dissappointing limitation I run into when converting my application to Firebird is that only one dataset can be returned from the stored procedure.

In MS TSQL, the following 4 SP or function types are supported:

1. Stored procedure (both return value and multiple recordsets can be returned, but it can not be used as a table in query)
2. Scalar function (only returns a scalar value, can be used in query)
3. Inline table-valued functions (return one recordset, can be used as a table in query)
4. Multi-statement table-valued functions (return one recordset, can be used as a table in query)

#1 does not seem to be supported by Firebird. From time to time I need to return multiple related dataset from one SP to support the application. But now in Firebird, I need to split the logic into separate SPs. Even more painful is that I need to rewrite the logic in client-side too!

Without some features, it's hard to switch from MS SQL to Firebird because of the big overhead involved in the converting & testing.

enlace (http://tracker.firebirdsql.org/browse/CORE-1186)

Creeria yo que si aún no posee esa característica si está reportada desde el 2007. No la implementarán dentro del futuro próximo.

¿Por cierto, has probado la integración de fedora directory para entornos empresariales con distribuciones basadas en RedHat? Podría ser una manera de consolidar tus entornos de trabajo en ese sistema operativo.

No la verdad no he usado linux desde hace un buen tiempo. :D

poliburro

08-11-2012, 23:51:01

Hombre, amigo Poliburro, ahí has soltado unas frases que se las trae :confused:

Y te diré el por qué decirlo... El documento que has remitido expone lo siguiente sobre postgresql:

Minimal custom tuning was implemented to the PostgreSQL database for all performance
measurements. The parameters modified are listed below.
Parameter Default Modified
autovacuum true false
checkpoint_timeout 5min 1h
effective_cache_size 3041205 4050045
max_connections 100 400
max_fsm_pages 7522049 10044817
max_fsm_relations 470128 627801
shared_buffers 988820 2640950
work_mem 261288 348211
Table 6: PostgreSQL Tuning

y de Sql server dice lo siguiente al respecto:

Already optimized for peak performance out of the box, no specific SQL Server tuning was
performed.

eso de entrada descalifica completamente la comparativa.... y luego el mismo documento establece que la conexión se hizo usando jbdc... por qué no usar la capa de conexión nativa de cada motor?

Y la cereza en el pastel... si observas la gráfica un postgresql obtimizado gana por poco a un mssql con instalación por default.

De ahí mis palabras... no puedes escrigrimir un argumento que no conoces y no validaste. esgrimirlo y que resulten esos detalles solo habla de usarlo sin mucho análisis.

Casimiro Notevi

09-11-2012, 00:10:01

egostar

09-11-2012, 00:25:41

No existen las comparaciones perfectas, siempre se puede obtener más o mejor rendimiento, nadie está contento ni satisfecho nunca, se haga como se haga.
Tú mismo lo has hecho, primero dices que no es comparable, para a renglón seguido decir que a pesar de ello está muy igualado.
Cualquier resultado sería discutible hacia cualquiera de los bandos. Todos los datos y gráficas son interpretables según el punto de vista de cada uno.

Aunque hay que dejar claro una cosa y ahí no vas a poder rebatirlo: ms sql server es muy caro, necesita un equipo windows y todos los programas, accesorios, utilidades, etc. Eso es pagar por ellos y sus licencias. Mucho dinero.

Un equipo postgresql (firebird, mysql, etc.) lo montas sobre un servidor linux y te ha costado en total... ¡¡¡ cero euros/dólares !!!

Hola

Pues como siempre digo, DEPENDE, DEPENDE, DEPENDE.

La mejor base de datos es la que te da lo que necesitas, ni mas ni menos.

Yo no creo que la razón de peso para elegir cualquier cosa no solo motor de base de datos gire en torno a su costo, aquí es ver los proyectos unitariamente. A veces ni siquiera es necesario utilizar una base de datos, con simples archivos XML incluso Paradox es mas que suficiente, pero a veces los clientes quieren pagar por una base de datos super cara....

No siempre lo mejor es lo ideal. ;)

Saludos

poliburro

09-11-2012, 02:49:31

No existen las comparaciones perfectas, siempre se puede obtener más o mejor rendimiento
¿Y entonces para que decir que es mejor X motor con una comparación imperfecta? Yo de viva mano puedo decirte que PostgreSql responde mejor que Sql Server cuándo separas los índices y los direccionas a un arreglo de discos de mayor velocidad y para eso no necesito documentos o comparaciones sesgadas.

Tú mismo lo has hecho, primero dices que no es comparable, para a renglón seguido decir que a pesar de ello está muy igualado.o ¿yo he dicho que no son comparables posgreSql y MsSql? ah caray ¿dónde?.

Todos los datos y gráficas son interpretables según el punto de vista de cada uno.
Cuándo se tratan datos duros y fidedignos eso no es verdad.

ms sql server es muy caro, necesita un equipo windows y todos los programas, accesorios, utilidades, etc

Si hablamos de precios, Oracle y Db2 Son más caros que SQl server y no por eso Sql server es mejor que ellos dos.

Si hablamos de un motor gratuito y multiplataforma yo elijo al ciento por cieto PostgreSql.

En resumen y con relación al tema de este hilo....

Agregaremos el retorno de múltiples resultsets a la lista de características que no soporta Firebird, Ok que no lo usas o no lo requieres ok, pero al final no lo soporta.

Yo por mi experiencia con los motores de bases de datos si tuviera que elejir un motor de base de datos gratuito y multiplataforma me iría por PostgreSql. Jamás por firebird, pero ese es mi punto de vista y si tu elijes Firebird, ok. muy bien ese es tu punto de vista.

Saludox

mightydragonlor

09-11-2012, 03:13:23

Me parece que un RDBMS debe remitirse a guardado y consulta de datos, esa opciones extras, me parecen que no son el fuerte del mismo, que trabaje con XML? para que? para eso no está en lenguaje de programación?, yo sólo me guío por facilidad de administración, de instalación, desempeño, multi-plataforma, soporte al standard Sql y mi experiencia me ha mostrado todo esto en Ms-Sql 2005 y Firebird 1.5, en lo personal prefiero Firebird y he hecho pruebas de desempeño en mi trabajo y si, Firebird me ha demostrado ser mas rápido, ambos instalados de fabrica, ahora varias cosas que había hecho en Firebird 1.5 las pasé a Firebird 2.5 y han mejorado bastante, así que no, no tengo quejas de Firebird, ni la mas mínima y si requiero cosas especiales, las hago con DDL, en Lazarus o las busco y punto, hay muchas, como por ejemplo, Full Text Seach, no me complico, uso lo que me gusta y para mi es la mejor opción.

Saludos.

Casimiro Notevi

09-11-2012, 11:25:46

¿Y entonces para que decir que es mejor X motor con una comparación imperfecta? Yo de viva mano puedo decirte que PostgreSql responde mejor que Sql Server cuándo separas los índices y los direccionas a un arreglo de discos de mayor velocidad y para eso no necesito documentos o comparaciones sesgadas.
Precisamente, amigo poliburro, las pruebas de comparaciones son para el resto de los x millones de personas que no lo han podido testear personalmente.

(los gráficos estadísticos) Cuándo se tratan datos duros y fidedignos eso no es verdad.
Las gráficas y resultados muestran lo que tú denominas "datos duros y fidedignos", correcto. Pero la interpretación que hace cada uno de esos datos sí que es distinta, por supuesto que es distinta para cada persona.

Si hablamos de un motor gratuito y multiplataforma yo elijo al ciento por cieto PostgreSql.
Muy buena elección, mis preferidos entre los libres (no porque sean gratuitos) y multiplataforma son firebird y postgresql. Este último es mucho más apropiado para muy grandes empresas porque admite clusters y otras características muy interesantes.

A donde yo quería llegar es que una empresa que necesita soluciones para sus servidores y sistemas de bases de datos... y ofrecerle ms sql server con windows... para mí eso no es ofrecerle una solución, eso es ofrecerle un problema, y caro.
De verdad que yo no puedo llegar a una empresa ofreciendo un servidor windows, me daría vergüenza ofrecer eso, bueno, no es que "me daría", es que "me da", no puedo hacerlo, es justo todo lo contrario a profesional y serio, tengo la sensación de estar engañándolos.
Otra cosa distinta es que esa empresa tenga un software que necesite por fuerza funcionar con windows, ahí no queda más remedio.

En resumen y con relación al tema de este hilo....
Agregaremos el retorno de múltiples resultsets a la lista de características que no soporta Firebird, Ok que no lo usas o no lo requieres ok, pero al final no lo soporta.
Pues no digo que sí ni tampoco digo que no, lo que puedo decir es que no lo sé porque nunca me había interesado por ello, aunque suena interesante y curioso.
Lo más que se ha podido comentar aquí es que alguien preguntó en 2007 por ello, de eso hace 5 años, no sé si lo habrán implementado.

Y en cuanto a las otra "larga lista" de cosas que no soporta firebird, leer xml o importar/exportar a excel, texto o csv... pues me parece ridículo, sin importancia, no es necesario (aunque hay utilidades de sobras para hacerlo) porque un RDBMS no tiene que dedicarse a esas cosas, tal y como dice mightydragonlor.

Espero que el "ardor" del debate no enturbie las relaciones personales :rolleyes:

poliburro

09-11-2012, 15:21:17

Y en cuanto a las otra "larga lista" de cosas que no soporta firebird, leer xml o importar/exportar a excel, texto o csv... pues me parece ridículo, sin importancia, no es necesario (aunque hay utilidades de sobras para hacerlo) porque un RDBMS no tiene que dedicarse a esas cosas, tal y como dice mightydragonlor.

Espero que el "ardor" del debate no enturbie las relaciones personales :rolleyes:

Es lógico que supongas que el soporte xml en una base de datos no tiene importancia. :) Pues entiendo que lo haces desde el punto de hablar sin saber. Pronto escribiré un artículo en mi blog sobre el manejo de XML en una base de datos.

Y no amigo... :) un debate, sin importar lo álgido, mientras no exceda los límites del insulto es siempre benéfico para todas las partes.

Saludos

roman

09-11-2012, 15:51:37

Es lógico que supongas que el soporte xml en una base de datos no tiene importancia. :) Pues entiendo que lo haces desde el punto de hablar sin saber. Pronto escribiré un artículo en mi blog sobre el manejo de XML en una base de datos.

Aunque, para aportar a este debate que comenzaste, bien podías aportar un poco aquí para iluminarnos, ¿no crees? :)

// Saludos

Casimiro Notevi

09-11-2012, 15:55:16

Es lógico que supongas que el soporte xml en una base de datos no tiene importancia. :) Pues entiendo que lo haces desde el punto de hablar sin saber.

Sí, es lo normal en mí, acostumbro a hablar sin saber.

roman

09-11-2012, 15:57:10

Y volviendo al tema original, ¿qué ventaja representa devolver tres recordsets en lugar de hacer un join normalito que enlace ls tres tablas?

Y sí. No lo sé. Por eso pregunto. :)

// Saludos

marcoszorrilla

09-11-2012, 16:06:06

Es lógico que supongas que el soporte xml en una base de datos no tiene importancia. :) Pues entiendo que lo haces desde el punto de hablar sin saber. Pronto escribiré un artículo en mi blog sobre el manejo de XML en una base de datos.

Y no amigo... :) un debate, sin importar lo álgido, mientras no exceda los límites del insulto es siempre benéfico para todas las partes.

No creo que tildar a alguien de hablar sin saber sea la mejor manera de entablar un debate, máxime cuando Casimiro no habla sin saber.

Un Saludo.

poliburro

09-11-2012, 16:33:15

Sí, es lo normal en mí, acostumbro a hablar sin saber.

Pues esa impresión me das estimado Casimiro, máxime cuando no me dices el por qué es irrelevante el uso de xml en bases de datos cuando es algo que está defino en el Ansi SQL

http://en.wikipedia.org/wiki/SQL/XML

movorack

09-11-2012, 16:42:10

Pues esa impresión me das estimado Casimiro, máxime cuando no me dices el por qué es irrelevante el uso de xml en bases de datos cuando es algo que está defino en el Ansi SQL

http://en.wikipedia.org/wiki/SQL/XML

Como bien dijiste. Mientras no se llegue al insulto.

----

Lo interesante de este debate es que la pregunta inicial nisiquiera ha sido contestada. ¿en la actualidad soporta o no devolver multiples recordset?. Habria que hacer las pruebas porque en google no he encontrado nada de eso.

Con respecto al debate:

No niego el grán rendimiento que tiene PostgreSQL y como mencionaron antes, en la vida real, el rendimiento depende mucho del diseño de la DB, la forma como el programa la utiliza, las técnologías para las comunicaciones y muchos factores. Y en mi experiencia he visto programas en Delphi y .Net conectados a MS-SQL, Oracle, Sybase, PostgreSQL e Informix ejecutar procesos muy lentos en servidores muy buenos.

Cuando una empresa me entrega la libertad de elegir el motor o puedo imponerlo :D, opto por PotgreSQL y en un pequeño programa POS que tengo los tiempos de respuesta son excelentes aún con un pc convencional con windows funcionando como servidor.

Pero si una empresa ya tiene una red montada con su datacenter, bases de datos, servicios de red, seguridad; Todo esto en windows, aunque suene como a blasfemia para casimiro, muchisimas empresas desde pequeñas hasta grandes basan su infraestructura en windows. Y de seguro pedirán que la nueva base de datos (la de nuestro aplicativo) se acomode a sus estandares de manejo y entre ello pedirán la integración del aplicativo con el active directory.

Si la eleción es PostgreSQL o firebird, habrá que instalar o crear algun producto que realice cambios en la seguridad del motor para asimilar los cambios en la seguridad de active directory y esto representa costos y posibles errores adicionales.

Para estos casos, lo mejor sería que nuestro aplicativo se acomode a muchos rdbms y si el cliente tiene MS-SQL, Oracle, MySQL, PostgreSQL o Firebird. Nuestro aplicativo pueda trabajar en todos ellos.

Lo mas seguro es que yo esté por otro camino del debate ya que ustedes han hablado mas del rendimiento uno vs otro pero para mi lo importante de elegir entre uno u otro depende de como beneficiará al cliente y como este se sentirá mas satisfecho. Por lo general a los gerentes (quienes firman los cheques) lo que les importa es la eficiencia en todo sentido y puede que para nosotros esos milisegundos sean muy importantes pero para estos dueños de empresas, lo que importa es cuanto costará un nuevo servidor nuevo teniendo un windows server instalado; Cuanto costará capacitar a su administrador de red para manejar un linux cuando el 99% de sus equipos es windows; Cuanto costará el nuevo soporte cuando ya tiene uno contratado y cuanto costará la integración de nuestro app con su esquema y protocolos.

Tener un aplicativo con esta felxibilidad es muy importante porque el cliente no deberá incurrir en costos adicionales de capacitación o contratación para un motor o un S.O. que normalmente no manejaban y en cambio entrega a nuestro aplicativo una valor agregado que marca la diferencia y nos termina representando la satisfacción del que firma el cheque y clientes finales y recomendaciones para nuevas oportunidades de negocio.

---
Algunas características en el rdbms ya sean ofrecidos desde instalación, característica adicional o complemento de tercero son muy importantes porque hacen que tu rdbms sea mas que un simple almacen de datos.

Por ejemplo, (en oracle) el manejo interno de XML permite consumir webservices desde los SP. Eso significaria que nuestro app solo llamaría un SP que consumiria el WS, validaria procesaría y almacenaria los resultados. El proceso sería muchisimo más rapido de seguro.

El cifrado de datos (Lo he visto en oracle con AES) podría ser muy funcional a la hora de almacenar información de vital para la compañía y que esté en el motor permitiría que los SP procesen y guarden datos cifrados sin la necesidad explicita que lo haga el app.

poliburro

09-11-2012, 16:52:26

Lo mas seguro es que yo esté por otro camino del debate ya que ustedes han hablado mas del rendimiento uno vs otro pero para mi lo importante de elegir entre uno u otro depende de como beneficiará al cliente y como este se sentirá mas satisfecho.

Total y absolutamente concuerdo contigo. A lo largo de mi vida profesional mi apertura a usar el servidor de base de datos que se ajuste a los requerimientos de mis clientes es lo que me ha permitido conocer múltiples y variadas soluciones....

Por cierto, veo que tu blog no está habilitado, considero que podrías aportar muchisimo espero que pronto escribas en él. Un saludo

roman

09-11-2012, 16:59:44

Y volviendo al tema original, ¿qué ventaja representa devolver tres recordsets en lugar de hacer un join normalito que enlace ls tres tablas?

Y, ¿hay respuesta para esto? O nos quedamos con que es parte del estandar :D

// Saludos

egostar

09-11-2012, 17:00:36

Bueno, cosas peores se han dicho aquí en los "debates" de la religión y de Apple, pero aún así, si vamos a ver con pinzas las palabras, pues....

Y en cuanto a las otra "larga lista" de cosas que no soporta firebird, leer xml o importar/exportar a excel, texto o csv... pues me parece ridículo, sin importancia, no es necesario (aunque hay utilidades de sobras para hacerlo) porque un RDBMS no tiene que dedicarse a esas cosas, tal y como dice mightydragonlor.

Pero al margen de todo esto, yo difiero un poco en relación a que una solución profesional y seria siempre sea una solución libre, para mi una solución "profesional y seria" es ofrecer todas las alternativas para que el cliente tenga en sus manos todos los panoramas. Una cosa son las preferencias y otra es ofrecer todas las alternativas y a partir de ahí dejarle ver los pros y los contras.

Y ésto por supuesto incluye a las bases de datos y sigo sosteniendo que la mejor base de datos es la que te permite hacer todo lo que necesitas, yo no veo el factor costo, eso al final es relativo, habrá clientes que paguen el costo de una base de datos costosa, habrá clientes que quieran una base de datos sin costo.

Y como dice Román, yo también quiero saber para que sirve lo propuesto en el título de este hilo.

Saludos

PD. Y que conste que mi aprecio tanto por Casimiro y por Poliburro es muy alto.

poliburro

09-11-2012, 17:32:44

Y, ¿hay respuesta para esto? O nos quedamos con que es parte del estandar :D

// Saludos

Amigo me avoco a tu duda planteada aquí:

Y volviendo al tema original, ¿qué ventaja representa devolver tres recordsets en lugar de hacer un join normalito que enlace ls tres tablas?

Y sí. No lo sé. Por eso pregunto. :)

Siguiendo el ejemplo que he posteado en mi blog, si tienes las tablas de encabezado de venta, detalle de venta e información de clientes. devolver toda esa información como un solo join normalito te genera una tabla con la siguiente estructura:

filasdatoscliente, datosencabezadoventa, partidadeventa1
filasdatoscliente, datosencabezadoventa, partidadeventa2
filasdatoscliente, datosencabezadoventa, partidadeventa3
...........
filasdatoscliente, datosencabezadoventa, partidadeventaN

como puedes observar, hacer uso de joins para devolverver toda esa información agrupada es sumamente infeciente pues vas a devolver un recordset con información duplicada y que te exigirá seprarla en tu código para mostrarla en los diferentes repositorios.

Lo que hace la mayoria de programadores es primero consultar el maestro de ventas, luego el detalle de venta y para terminar los datos del cliente. Es la manera tradicional y por cada llamada debes estar haciedno consultas separadas o llamando a los procedimientos almacenados correspondientes. Eso está muy bien, pero si buscas optimizar las llamadas a la base de datos y aprovechar una sola conexión, pues, podrías optar por devolver los tres bloques separados y de esa manera te ahorras todo el trabajo de estar invocando consultas separadas.

esta es una técnica como tantras otras. Podrías decirme que puedes deolverlo en un gran bloque xml, o podrías decirme que prefieres hacer tres consultas a la base de datos o podrías decirme que devolverás todo en un solo gran resultset. Eso queda ya en ti como programador y tus criterios técnicos.

Casimiro Notevi

09-11-2012, 17:45:04

...
Total y absolutamente concuerdo contigo. A lo largo de mi vida profesional mi apertura a usar el servidor de base de datos que se ajuste a los requerimientos de mis clientes es lo que me ha permitido conocer múltiples y variadas soluciones....
Estáis hablando de empresas que YA tienen instalado todo en windows, en ese caso es normal que no quieran cambiar, les da pánico.

Sobre el XML. Nadie ha dicho que no tenga sus especificaciones y sus normas y estándares. Lo que he dicho es que XML se usa para trapasar datos entre distintos programas (bases de datos/editores de textos/navegadores webs, etc.), pero el que un sistema de bases de datos RDBMS no tenga una función para leer o escribir ficheros XML no es importante. Suponiendo que firebird no lo tenga, hay muchas utilidades para importar/exportar datos XML con firebird, es más, se puede crear una UDF (función definida por el usuario), que es algo que sí tiene firebird... y ya tienes XML. Por eso digo que es algo ridículo y sin importancia. Ninguna base de datos va a ejecutar sentencias SQL contra un fichero de texto XML, sería ridículo, y si alguna lo hace... me parece más una curiosidad que algo práctico, pues debe ser ineficiente y lento a más no poder. Además de que entonces ¿para qué se usa una RDBMS?, ¿para trabajar con ficheritos de texto?

yo difiero un poco en relación a que una solución profesional y seria siempre sea una solución libre, para mi una solución "profesional y seria" es ofrecer todas las alternativas para que el cliente tenga en sus manos todos los panoramas. Una cosa son las preferencias y otra es ofrecer todas las alternativas y a partir de ahí dejarle ver los pros y los contras.
No recuerdo haber dicho eso, lo que he dicho es que windows no es una solución seria y profesional.

Casimiro Notevi

09-11-2012, 17:51:18

Amigo me avoco a tu duda planteada aquí:
Siguiendo el ejemplo que he posteado en mi blog, si tienes las tablas de encabezado de venta, detalle de venta e información de clientes. devolver toda esa información como un solo join normalito te genera una tabla con la siguiente estructura:

filasdatoscliente, datosencabezadoventa, partidadeventa1
filasdatoscliente, datosencabezadoventa, partidadeventa2
filasdatoscliente, datosencabezadoventa, partidadeventa3
...........
filasdatoscliente, datosencabezadoventa, partidadeventaN

como puedes observar, hacer uso de joins para devolverver toda esa información agrupada es sumamente infeciente pues vas a devolver un recordset con información duplicada y que te exigirá seprarla en tu código para mostrarla en los diferentes repositorios.

Si la idea es buena, es curioso, nadie ha dicho que sea malo, es interesante, etc.

Lo único que ha ocurrido en todo esto es que, sin saberlo, añadiste a tu comentario (sin venir a cuento): "algo más por agregar a la larga lista de cosas que no soporta firebird".
Porque de momento nadie ha podido decir si lo implementa o no. Que puede ser que no lo implemente... seguramente es así.
¡¡¡Tantas cosas hay que hacen unos y que no hacen otros!!!

roman

09-11-2012, 17:55:32

devolver toda esa información como un solo join normalito te genera una tabla con la siguiente estructura:

filasdatoscliente, datosencabezadoventa, partidadeventa1
filasdatoscliente, datosencabezadoventa, partidadeventa2
filasdatoscliente, datosencabezadoventa, partidadeventa3
...........
filasdatoscliente, datosencabezadoventa, partidadeventaN

como puedes observar, hacer uso de joins para devolverver toda esa información agrupada es sumamente infeciente pues vas a devolver un recordset con información duplicada y que te exigirá seprarla en tu código para mostrarla en los diferentes repositorios.

Lo que hace la mayoria de programadores es primero consultar el maestro de ventas, luego el detalle de venta y para terminar los datos del cliente. Es la manera tradicional y por cada llamada debes estar haciedno consultas separadas o llamando a los procedimientos almacenados correspondientes. Eso está muy bien, pero si buscas optimizar las llamadas a la base de datos y aprovechar una sola conexión, pues, podrías optar por devolver los tres bloques separados y de esa manera te ahorras todo el trabajo de estar invocando consultas separadas.

Gracias por la respuesta :)

No dudo que pueda tener sus ventajas. Y no lo dudo para empezar porque ni siquiera tenía conocimiento de esta característica hasta hace unas horas.

Pero, sin ánimo de demeritar, no me parece que tu ejemplo sea clarificador. Para empezar, lo de los datos repetidos, pues todo depende de no hacer un select .* y escoger los campos adecuados de cada tabla.

Normalmente, lo que hacemos es un join para mostrar los datos más relevantes en una rejilla, y entonces hacer la o las consultas extras sólo para los registros que realmente nos interese. Es decir, no significa que vamos a hacer las consultas extra por cada uno de los registros de la consulta principal.

Entonces, a lo que me refiero, es que no veo, al menos en este caso específico, una clara ventaja.

-------

Por otra parte, un poco al margen; mencionas que además de SQL Server, hay oros motores que soportan la característica. En el caso particular de MySQL, yo ni siquiera lo mencionaría. Las pruebas que he hecho con procedimientos almacenados (ver. 5.1.x) dejan mucho que desear, dando resultados extremadamente lentos.

// Saludos

poliburro

09-11-2012, 17:57:07

Lo único que ha ocurrido en todo esto es que, sin saberlo, añadiste a tu comentario (sin venir a cuento): "algo más por agregar a la larga lista de cosas que no soporta firebird".
Porque de momento nadie ha podido decir si lo implementa o no.

claro que fué sin saberlo y por eso precisamente lo dije de la siguiente manera:

No se si lo soporte Firebird, supongo que sería algo más por agregar a la larga lista de "cosas" que no soporta.

Aclaré que no lo sabia y que de no soportarlo sería algo por agregar a la larga lista de "cosas" que no soporta.

Jamás me mostré como un experto en firebird sin saber del tema. :) No conozco firebird tan a profundidad como para poder declarar que no soporta algo.

roman

09-11-2012, 17:57:29

Si la idea es buena, es curioso

O sea, ¿es curioso sólo cuando la idea es buena? :p

¿O te refieres a sí, la idea es buena, es curioso...? :D

// Saludos

Casimiro Notevi

09-11-2012, 17:58:32

O sea, ¿es curioso sólo cuando la idea es buena? :p

¿O te refieres a sí, la idea es buena, es curioso...? :D

Me comí la coma :p

Casimiro Notevi

09-11-2012, 18:05:04

claro que fué sin saberlo y por eso precisamente lo dije de la siguiente manera:
Aclaré que no lo sabia y que de no soportarlo sería algo por agregar a la larga lista de "cosas" que no soporta.

Ya, y también puede ser algo a agregar a interbase, mongodb, informix, netezza, ingress, sqlite, dbase, foxpro... :confused:

poliburro

09-11-2012, 18:10:02

Ya, y también puede ser algo a agregar a interbase, mongodb, informix, netezza, ingress, sqlite, dbase, foxpro... :confused:

pues si.. solo que en este hilo se delimitó desde el inicio claramente a Firebird... o me equivoco?

Casimiro Notevi

09-11-2012, 18:14:41

pues si.. solo que en este hilo se delimitó desde el inicio claramente a Firebird... o me equivoco?

En eso te doy la razón.

poliburro

09-11-2012, 18:16:14

Normalmente, lo que hacemos es un join para mostrar los datos más relevantes en una rejilla, y entonces hacer la o las consultas extras sólo para los registros que realmente nos interese. Es decir, no significa que vamos a hacer las consultas extra por cada uno de los registros de la consulta principal.

Entonces, a lo que me refiero, es que no veo, al menos en este caso específico, una clara ventaja.// Saludos

Exacto¡¡¡¡¡¡¡¡... precisamente la técnica solo es útil para cuando debes hacer múltiples consultas a la base de datos para traterte varios recordsets.

Por otra parte, un poco al margen; mencionas que además de SQL Server, hay oros motores que soportan la característica. En el caso particular de MySQL, yo ni siquiera lo mencionaría. Las pruebas que he hecho con procedimientos almacenados (ver. 5.1.x) dejan mucho que desear, dando resultados extremadamente lentos.

caray Román, pues ahí si que puedo decirte, siempre he creido que esa parte está ligada al conocimiento que tenga el diseñador de la administración de bases de datos, del diseño de la base de datos y de la puesta a punto del motor.

Yo tengo un sistema con php y mysql con tablas de más de dos millones de registros y tamaños del órden de gigas de información. y me responde extremadamente rápido con procedimientos almaceandos con una carga de más de 50 usuarios simultáneos escribiendo y consultando.

roman

09-11-2012, 18:20:59

Tendría que revisarlos. Porque ciertamente no soy ducho en eso. Se trataba de uns procedimientos que se limitaban a hacer sencillas operaciones de stringsy numéricas para, por ejemplo, calcular el dígito verificador de la homoclave de un RFC. Y era muy lento. Es decir, no había realmente consultas a la base, de manera que pienso que no entraban en juego cuestiones de diseño.

// Saludos

Osorio

09-11-2012, 18:23:34

poliburro

09-11-2012, 19:51:48

Bueno al margen de lo demás.

Si utilizamos DBExpress + DataSnap estas soluciones de traer conjuntos de datos con sus "hijos", y los hijos de sus hijos, y los hijos de los hijos de sus hijos, etc. se pueden implementar muy facil. Lo mejor es que no importa si el motor lo soporta o no.

Mas o menos ventajas? no se.

Saludos.

Personalmente uso más ADO que DbExpress así que si te animas a compartir como se hace con esos componentes sería muy interesante y útil para la biblioteca de técnicas. Saludox

Osorio

09-11-2012, 21:42:35

Así de rapidito hice un pequeñito ejemplo con DBExpress pero sin dataSnap para ilustrar lo que me pasó por la mente cuando vi el tema.

Para los que quieran profundizar en el tema pueden ver:

La cara oculta de delphi 6: Paginas 705-707 para empezar.

Si esto no pega con el tema de conversación, ehhh. Bueno, a alguien le servirá.

Saludos.

poliburro

09-11-2012, 21:45:00

Osorio

10-11-2012, 01:49:34

Hagale, con tal que le sirva a la comunidad.

Saludos.

cointec

11-11-2012, 12:04:56

Hola a todos, he leído el hilo, aunque me ha parecido poco interesante y nada constructivo. No entiendo cosas que se han dicho y entiendo que cosas que se han dicho tendrían mejor aceptación si se hubiesen dicho de otra forma.

Aunque no es el tema de este hilo, me gustaría dar mi opinión sobre algo que se ha comentado. Me ha parecido entender que las cosas son buenas por ser gratis o quizá las cosas gratis son buenas...

Yo utilizo firebird y estoy muy contentó con el en muchos aspectos. Puede que tenga carencias, pero por ahora no he necesitado las cosas de las que carece, o las he cubierto fuera del motor, o quizá sí tuviese más funcionalidades las utilizaría. Firebird, desee mi punto de vista,no es un producto gratuito, aunque lo puedes descargar y utilizar sin coste alguno. En el hay un equipo de personas que trabajan y viven de el y es un proyecto que seguirá vivo, mientras haya gente que lo apoye, principalmente económicamente. No creo que existan cosas "gratis". Creo que firebird tendría muchas más funcionalidades si la comunidad de usuarios le devolviera algo de lo que firebird ha dado a la comunidad. Eso permitiría que se evolucionase y que cada vez nos proporcionase más servicios y características.

Si firebird no ha evolucionado en mayor medida es porque no ha tenido el apoyo económico que puede haber tenido mysql o postgresql y al final todo depende de dinero, aunque sea "gratuito". ¿Vosotros trabajaríais gratuitamente con el único aliciente que en los foros digan que vuestro trabajo es bueno por qué a gente que se aprovecha de él diga que le ha salido gratis? ¿Cuanto tiempo soportaría vuestra empresa trabajando gratuitamente?.

Firebird, como muchos otros proyectos te permiten empezar algo sin coste en licencias, pero su objetivo final es que si tienes éxito, devuelvas algo de lo que firebird te ha dado. Es algo de lo que deberíamos ser conscientes. Si preocupa el futuro de firebird, deberíamos empezar a plantearnos como apoyar lo económicamente. La ventaja de este tipo de proyectos es que no requiere un coste fijo y cada uno lo puede apoyar en mayor o menor medida, pero al final ese apoyo permitirá que siga vivo y en continúa evolución.

Por otro lado, el tema del hilo quizá se podría solucionar con GTT. Un procedimiento almacenado puede almacenar registros en tablas temporales y dichos registros pueden ser visibles a nivel de conexión o transacción, por lo que una vez rellenados los registros desde el procedimiento almacenado, se podrían recuperar mediante DML desde la aplicación. De esta forma, tendrías como resultado tantos recorsets como desees.

poliburro

12-11-2012, 17:23:07

Firebird, desee mi punto de vista,no es un producto gratuito, aunque lo puedes descargar y utilizar sin coste alguno. En el hay un equipo de personas que trabajan y viven de el y es un proyecto que seguirá vivo, mientras haya gente que lo apoye, principalmente económicamente. No creo que existan cosas "gratis". Creo que firebird tendría muchas más funcionalidades si la comunidad de usuarios le devolviera algo de lo que firebird ha dado a la comunidad. Eso permitiría que se evolucionase y que cada vez nos proporcionase más servicios y características.

Totalmente de acuerdo... y es una lástima que precisamente Open source signifique para muchos "gratis" y lo peor es que cobren por ello y jamás devuelvan a la comunidad parte de las ganancias....

egostar

12-11-2012, 17:43:38

Totalmente de acuerdo... y es una lástima que precisamente Open source signifique para muchos "gratis" y lo peor es que cobren por ello y jamás devuelvan a la comunidad parte de las ganancias....

Indudablemente, yo se de algunas casos; que pudiendo por lo menos dar unas palabras de aliento, ya no digamos apoyo económico que pareciera mucho pedir, y no lo hacen. Es triste pues, pero que le vamos a hacer.....

"Es difícil hacer que un saco vacío se pare derecho"
-Benjamín Franklin

poliburro

12-11-2012, 17:45:45

Indudablemente, yo se de algunas casos; que pudiendo por lo menos dar unas palabras de aliento, ya no digamos apoyo económico que pareciera mucho pedir, y no lo hacen. Es triste pues, pero que le vamos a hacer.....

"Es difícil hacer que un saco vacío se pare derecho"
-Benjamín Franklin

Si amigo... y lo peor es que muchos de ellos, son precisamente los que defienden a capa y espada la "gratuidad"....

En fin, remarco tu cita

"Es difícil hacer que un saco vacío se pare derecho"
-Benjamín Franklin

roman

12-11-2012, 17:50:31

Totalmente de acuerdo... y es una lástima que precisamente Open source signifique para muchos "gratis" y lo peor es que cobren por ello y jamás devuelvan a la comunidad parte de las ganancias....

Y, ¿por qué no habrían de hacerlo?

Cito aquí textual del sitio de firebird:

FREE LIKE FREE BEER. No fees for download, registration, licensing or deployment, even you distribute Firebird as part of your commercial software package.

Es decir, en el caso de Firebird, significa exactamente eso, gratis.

Cierto que los siguientes dos párrafos dicen:

Firebird's development depends on voluntary funding by people who benefit from using it. Funding options range from donations, through Firebird Foundation memberships to sponsorship commitments.

Choosing Firebird and saving or making money by your choice? Show your appreciation and encouragement by contributing money in proportion to these benefits.

Pero eso ya queda a la conciencia de cada quien. Pero de que es gratuito como en free beer, me parece que es bastante claro.

// Saludos

mightydragonlor

12-11-2012, 17:53:42

Y, ¿por qué no habrían de hacerlo?

Cito aquí textual del sitio de firebird:

Es decir, en el caso de Firebird, significa exactamente eso, gratis.

Cierto que los siguientes dos párrafos dicen:

Pero eso ya queda a la conciencia de cada quien. Pero de que es gratuito como en free beer, me parece que es bastante claro.

// Saludos

Si y no, es decir, si es gratuito, pero si queremos que siga así, hay que apoyar de forma económica por pequeña que sea, ya que las personas que desarrollan Firebird, y otras muchos mas RDBMS libres, necesitan comer, y si el proyecto no les da de comer se van a una empresa a trabajar por el pan de cada día.

Saludos.

poliburro

12-11-2012, 17:56:27

Si y no, es decir, si es gratuito, pero si queremos que siga así, hay que apoyar de forma económica por pequeña que sea, ya que las personas que desarrollan Firebird, y otras muchos mas RDBMS libres, necesitan comer, y si el proyecto no les da de comer se van a una empresa a trabajar por el pan de cada día.

Saludos.

Muy cierto.. al final ellos que desarrollan hacen una inversión en Luz, alimentos, tiempo.. me parece terrible escudarse en una licencia para no devolverles parte de lo invertido....

roman

12-11-2012, 18:07:44

Si y no, es decir, si es gratuito, pero si queremos que siga así, hay que apoyar de forma económica por pequeña que sea, ya que las personas que desarrollan Firebird, y otras muchos mas RDBMS libres, necesitan comer, y si el proyecto no les da de comer se van a una empresa a trabajar por el pan de cada día.

Saludos.

Pero eso ya es una cuestión moral. ¿Cuántos de aquí, por ejemplo, han donado un centavo a wikipedia? El caso es que aquí se dijo que muchos confunden open source con gratuito y que lo peor es que cobran por ello. Bueno, estrictamente hablando, eso lo permite la licencia de Firebird.

// Saludos

egostar

12-11-2012, 18:19:31

Casimiro Notevi

12-11-2012, 19:09:28

cointec

12-11-2012, 19:24:53

Pero eso ya es una cuestión moral. ¿Cuántos de aquí, por ejemplo, han donado un centavo a wikipedia? El caso es que aquí se dijo que muchos confunden open source con gratuito y que lo peor es que cobran por ello. Bueno, estrictamente hablando, eso lo permite la licencia de Firebird.

Hola, si utilizase wikipedia profesionalmente y obtuviese dinero de él, lo más ético sería apoyarlo económicamente.

Desde mi punto de vista, el software libre, open source, etc. lo que aportan es que no tienen un coste de licencias, pero eso no significa que no busquen obtener un dinero a cambio. El core de desarrollo de Firebird lo componen 4 personas, y existe un grupo adicional encargado de realizar los drivers .Net, java, QA, etc. Ese equipo de desarrollo, lo mantienen actualmente un conjunto de empresas que utilizan firebird y obtienen un beneficio de él y quieren que el proyecto firebird continue. Sin este apoyo económico, que podría ser mayor si la comunidad se concienciara, Firebird habría desaparecido hace años.

Sólo nos tenemos que plantear algunas preguntas. ¿Que ocurriría sio desapareciese firebird o su desarrollo discontinuara? ¿Que coste tendría cambiar nuestros proyectos a otro SGBD? ¿Como nos afectaría económicamente? Si alguna de estas respuestas nos afectan, sólo hay que cuantificarlo y ver en que se puede apoyar al proyecto. El primero en obtener un beneficio sería uno mismo.

Creo que cualquiera, independientemente de la dimensión de sus proyectos, puede aportar algo al proyecto y el primer beneficiado es uno mismo. No sé porque, pero nunca he creido en la gratuidad en entornos empresariales, donde se obtiene un beneficio del trabajo de otros, que por supuesto, no lo hacen por amor al arte y seguro que al final de cada mes pagan sus hipotecas e incluso comen a diario.

poliburro

12-11-2012, 19:40:28

Me parece casi normal que un programador independiente o una pequeñita empresa que no tenga recursos "pasen" de ayudar económicamente a firebird (postgresql, wikipedia o lo que sea... libre y gratis), lo que no me parece nada ético (aunque puede hacerlo legalmente al igual que los anteriores citados) es que empresas como Embarcadero se aprovechen y usen software libre y gratis para su beneficio (Free Pascal Compiler) y no den ni las gracias a los creadores.
Luego irán "rajando" del software libre, que es muy malo, inestable, inseguro, etc. pero bien que lo han usado cuando le han hecho falta.

Creo sincesarmente que escudarse en la dimensión de nuestros proyectos es actual de mala fe... es más sencillo echar la culpa a los grandes que hacer un análisis a conciencia interno.

Que sucederá si esos miles de programadores que usan firebird decidieran incrementar en 50 dolares el costo de su proyecto y eso entregarlo a los desarrolladores de firebird?... seguramente el proyecto tendría dimensiones mayores a las actuales. por que como bien dice el compañero cointec:

Creo que cualquiera, independientemente de la dimensión de sus proyectos, puede aportar algo al proyecto y el primer beneficiado es uno mismo. No sé porque, pero nunca he creido en la gratuidad en entornos empresariales, donde se obtiene un beneficio del trabajo de otros, que por supuesto, no lo hacen por amor al arte y seguro que al final de cada mes pagan sus hipotecas e incluso comen a diario.

roman

12-11-2012, 19:56:53

poliburro

12-11-2012, 20:11:46

Es curioso como se omite responder ciertas cosas... :rolleyes:

Si los desarrolladores de Firebird no estuvieran de acuerdo en que haya gente que use su producto sin pagar un céntimo, escogerían otro tipo de licencia. No hay que ser más papistas que el papa. ;)

// Saludos

Es cierto. Los desarrolladores permiten su uso sin costos de ningún tipo, pero como mencionaba previamente. Entonces por esa mera razón no merecen que se les retribuya por su trabajo? o bajo la premisa de que es libre defendamos a ultranza su gratuidad sin detenernos en las consideraciones que bien ha mencionado el compañero cointec?

egostar

12-11-2012, 20:23:03

Si los desarrolladores de Firebird no estuvieran de acuerdo en que haya gente que use su producto sin pagar un céntimo, escogerían otro tipo de licencia.

Asi es, esa es y ha sido su decisión, ojalá y no se vean tan apretados como la wiki para pedir de forma más "clara" el aporte de todos los que usan esta excelente base de datos.

Saludos

roman

12-11-2012, 20:24:02

Entonces por esa mera razón no merecen que se les retribuya por su trabajo?

Claro que lo merecen. Pero si alguien no lo hace (retribuirles), ¿por qué hemos nosotros de criticar esa postura que los mismos creadores no hacen? Si lo hicieran entonces cambiarían de licencia.

// Saludos

poliburro

12-11-2012, 20:34:28

Claro que lo merecen. Pero si alguien no lo hace (retribuirles), ¿por qué hemos nosotros de criticar esa postura que los mismos creadores no hacen? Si lo hicieran entonces cambiarían de licencia.

// Saludos

o como menciona Eliseo, al igual que la wiki tendrán que "pedir" de manera clara las aportaciones que requieren para poder subsistir....

En fin que como dice nuestro compañero que sea libre no necesariamente significa gratis.

cointec

12-11-2012, 20:38:33

Claro que lo merecen. Pero si alguien no lo hace (retribuirles), ¿por qué hemos nosotros de criticar esa postura que los mismos creadores no hacen? Si lo hicieran entonces cambiarían de licencia.

Hola Román, creo que aquí no se ha criticado a nadie por no retribuir y el objetivo no es criticar, más bien concienciar, que es algo bastante distinto. Tampoco hablo de las retribuciones de los desarrolladores de Firebird o si deben ganar más o menos o si deben haber más o menos desarrolladores, o cuanto debe aportar quien lo utiliza, etc.

Hablo de que si no nos implicamos en los proyectos que utilizamos para obtener un beneficio de ellos, puede que algún día nos quedemos sin proyecto suyo ni nuestro. No me gustan los extremos, pero si todo el mundo mirase para otro lado y no apoyara Firebird, al igual que otros proyectos, no existiría y desaparecería, que por cierto es algo que no me gustaría.

roman

12-11-2012, 20:41:41

En fin que como dice nuestro compañero que sea libre no necesariamente significa gratis.

Y va de vuelta... :rolleyes:

Léanse, una vez más, lo que dice el sitio de Firebird. En este caso SÍ significa gratuito.

// Saludos

roman

12-11-2012, 20:50:18

Hola, si utilizase wikipedia profesionalmente y obtuviese dinero de él, lo más ético sería apoyarlo económicamente.

Desde mi punto de vista, el software libre, open source, etc. lo que aportan es que no tienen un coste de licencias, pero eso no significa que no busquen obtener un dinero a cambio. El core de desarrollo de Firebird lo componen 4 personas, y existe un grupo adicional encargado de realizar los drivers .Net, java, QA, etc. Ese equipo de desarrollo, lo mantienen actualmente un conjunto de empresas que utilizan firebird y obtienen un beneficio de él y quieren que el proyecto firebird continue. Sin este apoyo económico, que podría ser mayor si la comunidad se concienciara, Firebird habría desaparecido hace años.

Sólo nos tenemos que plantear algunas preguntas. ¿Que ocurriría sio desapareciese firebird o su desarrollo discontinuara? ¿Que coste tendría cambiar nuestros proyectos a otro SGBD? ¿Como nos afectaría económicamente? Si alguna de estas respuestas nos afectan, sólo hay que cuantificarlo y ver en que se puede apoyar al proyecto. El primero en obtener un beneficio sería uno mismo.

Creo que cualquiera, independientemente de la dimensión de sus proyectos, puede aportar algo al proyecto y el primer beneficiado es uno mismo. No sé porque, pero nunca he creido en la gratuidad en entornos empresariales, donde se obtiene un beneficio del trabajo de otros, que por supuesto, no lo hacen por amor al arte y seguro que al final de cada mes pagan sus hipotecas e incluso comen a diario.

Disculpa, se me había pasado este mensaje.

Yo estoy de acuerdo con lo que dices (y eso que no uso FireBird). Moralmente es loable retribuir en la medida que uno pueda a este tipo de proyectos. Incluso a la wikipedia pues, ¿qué significa usar profesionalmente la wikipedia? La mayoría de nosotros la utiliza diariamente para una u otra cosa y ese uso cuesta.

Pero cuando se usan frases como "lo peor es que hay quien cobra por ello y no devuelve a la comunidad parte de las ganancias", es cuando yo pregunto: ¿y porqué no habrían de hacerlo? si la licencia lo permite. Hay ahí una crítica implicita que, me parece no es válida puesto que ni a los creadores, en este caso, de Firebird, la hacen.

// Saludos

poliburro

12-11-2012, 21:34:10

Hay ahí una crítica implicita que, me parece no es válida puesto que ni a los creadores, en este caso, de Firebird, la hacen.

// Saludos

Es cierto... los desarrolladores no realizan ninguna crítica, pero si hay una solicitud explicita de apoyo económico...

The Firebird database engine has a strong following amongst the developer and user communities. Firebird Foundation is an organisation of these individuals and companies of various sizes, working together as parts of a non-profit organisation that aims to ensure the continued development of the open source Firebird relational database and related products.

The dues paid by members play an important part in directly funding development of the Firebird engine. A list of the current membership is available here (http://www.firebirdsql.org/en/members). As a foundation, we are serious about maintaining a financial backbone for the database development and so our members regard it as a privilege to pay subscriptions for membership.

y regresamos al mismo punto. si es gratis, si puedes usarlo sin pagar un solo céntimo Pero que tan válido es hacerlo y ufanarse de ello?

http://www.firebirdsql.org/en/firebird-foundation/

Casimiro Notevi

12-11-2012, 21:41:59

Creo sincesarmente que escudarse en la dimensión de nuestros proyectos es actual de mala fe... es más sencillo echar la culpa a los grandes que hacer un análisis a conciencia interno.

Si realizo un proyecto que me deja un cierto beneficio, no me importa pagar/donar una cantidad a firebird (o al creador del software que sea).
Pero una empresa grande que aprovecha el software de otro para añadirlo a su propio software, pienso que sí debería de recompensar generosamente a la otra empresa. Aunque también he dicho "que ni siquiera dio las gracias", ¡¡¡qué menos!!!, un simple comentario informando que se usa el software de otro y darle las gracias.

En la empresa que estuve trabajando antes de esta última sólo se usaba software libre para todo, cada componente, cada utilidad, cada software que se necesitó fue pagado con la cantidad "recomendada" por el creador. Incluso a firebird también se le pagó, creo recordar que alrededor de 16000 dólares al cambio, y eso fue ya hace unos años. No es por ponerme medallas, yo no fui quien pagó, fue la empresa donde trabajaba, yo sólo aconsejé hacerlo para que siguieran funcionando y porque nos habíamos ahorrado muchísimo dinero en relación a haber decidido usar "otros softwares privativos/cerrados muy caros".

egostar

12-11-2012, 22:02:05

Hola

No hay que irse tan lejos amigo Casi, hay algo que no miente y son las estadísticas,

El "éxito" de un hilo cuando el asunto es de algo gratis (http://www.clubdelphi.com/foros/showthread.php?t=22545)
Y el "desinterés" cuando algo es de pago (http://www.clubdelphi.com/foros/showthread.php?t=81120)

Es decir, es mejor o más interesante el programa de nuestro amigo David que el trabajo de jachguate por el simple hecho de ser gratuito ? Yo no creo, es más útil, no lo sé, lo que si sé es que son dos trabajos que bien deberían estar colgados en la pared porque son emanados de compañeros que han dejado muchas cosas buenas aquí.

Y si, en ese aspecto yo si soy mas papista que el papa, como hace algunos años (para ser exactos en 2006) me lo dijeron aquí mismo.

Saludos

roman

12-11-2012, 22:18:20

¡Valgame! ¡Que andamos meando fuera del tarro! :eek:

Hombre, nada que ver una cosa con la otra amigo.

// Saludos

Casimiro Notevi

12-11-2012, 22:27:56

Hola
No hay que irse tan lejos amigo Casi, hay algo que no miente y son las estadísticas,
El "éxito" de un hilo cuando el asunto es de algo gratis (http://www.clubdelphi.com/foros/showthread.php?t=22545)
Y el "desinterés" cuando algo es de pago (http://www.clubdelphi.com/foros/showthread.php?t=81120)
Es decir, es mejor o más interesante el programa de nuestro amigo David que el trabajo de jachguate por el simple hecho de ser gratuito ? Yo no creo, es más útil, no lo sé, lo que si sé es que son dos trabajos que bien deberían estar colgados en la pared porque son emanados de compañeros que han dejado muchas cosas buenas aquí.
Y si, en ese aspecto yo si soy mas papista que el papa, como hace algunos años (para ser exactos en 2006) me lo dijeron aquí mismo.
Saludos

Creo que eso es por el título llamativo de dec, imagina si llega a poner algo como: "chicas en bikini, gratis" :)

roman

12-11-2012, 22:37:19

No, no, pero te quedas corto.

Vamos, nada que ver.

Para empezar, el hilo de dec lo comenzó cuando era un usuario (altamente) activo mientras que jachguate hace mucho tiempo que no se pasa por aquí y ni siquiera comenzó él el hilo.

El tema del hilo de dec es de caracter muy general mientras que el de jachguate sólo unos cuantos entienden de qué trata y menos aún lo requieren o lo llevan la práctica. Pero, sobre todo, es que no ha habido ningún intento por involucrar a la comunidd en una discusión acerca del tema.

El hilo de dec lleva ya muchos mensajes en que trata de un software de pago, y, aún así sigue adelante.

Desde luego que no se trata de comparar los beneficios de uno u otro. Y tan apreciamos lo que jachguate dio en su momento al club, que sigue siendo moderador.

Pero, en lo que se refiere a foros, a aprendizaje, el hilo de dec se ha prestado para un montón de intercambio de ideas, pocas de las cuales versan alrededor de: ah! como es gratis vamos a participar aquí.

No, no, es un comparación injusta y fuera de lugar.

// Saludos

egostar

12-11-2012, 22:50:23

¡Valgame! ¡Que andamos meando fuera del tarro! :eek:

Hombre, nada que ver una cosa con la otra amigo.

// Saludos

Creo que eso es por el título llamativo de dec, imagina si llega a poner algo como: "chicas en bikini, gratis"

El tema del hilo de dec es de caracter muy general mientras que el de jachguate sólo unos cuantos entienden de qué trata y menos aún lo requieren o lo llevan la práctica. Pero, sobre todo, es que no ha habido ningún intento por involucrar a la comunidd en una discusión acerca del tema.

No, no, es un comparación injusta y fuera de lugar.

Lo acepto, me parece que no debi meter a esta "discusion" el tema y me disculpo por ello

Saludos

poliburro

12-11-2012, 23:04:54

No, no, es un comparación injusta y fuera de lugar.

// Saludos

Injusta no lo se, fuera de lugar no lo creo... aquí se está defendiendo la gratuidad y el ejemplo que ha puesto egostar es claro. Cuando es gratis todo mundo se interesa pero cuando algo cuesta a nadie le importa...

Hay un dicho en México que lo refleja: "Gratis hasta unas puñaladas"

Es verdad que pocos conocen del tema pero me pregunto... habría tenido tan poca asistencia si el tema fuera que se regalaba ese libro?

Casimiro Notevi

12-11-2012, 23:18:22

Pienso que igual de concurrido, por ejemplo, yo no sabía que fuese de pago, sólo vi el anuncio y pensé "vaya, para cuando me haga falta ya sé a donde debo acudir por un libro sobre este tema", no llegué siquiera a profundizar para ver si era de pago o gratis o libre.

roman

13-11-2012, 01:08:07

Injusta no lo se, fuera de lugar no lo creo... aquí se está defendiendo la gratuidad y el ejemplo que ha puesto egostar es claro. Cuando es gratis todo mundo se interesa pero cuando algo cuesta a nadie le importa...

Hay un dicho en México que lo refleja: "Gratis hasta unas puñaladas"

Es verdad que pocos conocen del tema pero me pregunto... habría tenido tan poca asistencia si el tema fuera que se regalaba ese libro?

Vamos a ver. ¿Qué tipo de interés esperabas? El hilo tiene 368 visitas en un mes, nada mal. ¿Esperabas 368 mensajes diciendo "gracias"? No tiene punto de comparación un hilo que abre la posibilidad a discusión que uno que simplemente es una noticia. Y eso nada tiene que ver con la calidad de uno u otro ni tampoco con la gratuidad. Para el caso, estos foros, en su totalidad, ni siquiera existirían pues Delphi es un producto de pago (y muy alto).

// Saludos

egostar

13-11-2012, 16:29:19

Vamos a ver. ¿Qué tipo de interés esperabas? El hilo tiene 368 visitas en un mes, nada mal. ¿Esperabas 368 mensajes diciendo "gracias"? No tiene punto de comparación un hilo que abre la posibilidad a discusión que uno que simplemente es una noticia. Y eso nada tiene que ver con la calidad de uno u otro ni tampoco con la gratuidad. Para el caso, estos foros, en su totalidad, ni siquiera existirían pues Delphi es un producto de pago (y muy alto).

// Saludos

Ciertamente, fué desmedida mi compraración entre esos dos hilos, debí buscar uno que tuviese las mismas características.

Y si, encontré uno que tiene características "similares". La cara oculta de delphi 6 (regalo de Ian Marteens).

Saludos

Casimiro Notevi

13-11-2012, 16:36:38

36 respuestas en 2 años, las visitas aumentan bastante todos los días por culpa de los 'bots' de google, microsoft, etc.
Habrá que esperar un par de años para comparar :)

Casimiro Notevi

13-11-2012, 16:44:31

Yo creo, sinceramente, que la diferencia de "popularidad" es debida única y exclusivamente a que el libro del amigo jachguate es muy técnico y avanzado, su temática no está al alcance de cualquiera, fíjate que la mayoría de usuarios que hay por aquí son bastante novatos, no tienes más que ver las preguntas que hacen y lo confundidos que están, que todavía no entienden ni lo más básico de la programación, no digamos ya sobre delphi.

Y como todo libro muy técnico, nivel avanzado y temática muy "vertical", tiene un público muy "filtrado", más bien gente bastante experta. No es un libro para "las masas" aficionadas de delphi.

roman

13-11-2012, 16:51:43

Estaba preparando una respuesta pero he decidido no hacerlo, porque argumentar el porqué un hilo de Marteens tiene más popularidad que un hilo de jachguate podría confundirse con restarle méritos a Juan Antonio y estoy muy lejos de eso.

Simplemente diré, que, más que defender un punto, da la impresión de que tienen cierto rencor por no haber visto aquí una recepción más abultada a la traducción del libro de Programación Paralela, un rencor, que ni siquiera sé si el propio Juan Antonio tiene.

// Saludos

egostar

13-11-2012, 17:19:24

:) No hombre, cual rencor, era sólo para ejemplificar la diferencia entre algo gratuito y algo de pago, no se vayan por otro lado, además ésto lo hago a titulo personal, nada tiene que ver Juan.

Saludos

poliburro

13-11-2012, 18:02:37

Simplemente diré, que, más que defender un punto, da la impresión de que tienen cierto rencor por no haber visto aquí una recepción más abultada a la traducción del libro de Programación Paralela,
// Saludos

ah caray... ¿qué no se trataba el hilo de gratis vs paga? y precisamente el ejemplo demuestra la buena acogida que recibe lo gratis contra lo de paga? Sin ser precisamente ese factor la clave para una buena elección de producto? Creo que andas mirando moros dónde no hay...

Bueno, ajustandonos al debate. En lo personal jamás he tenido problema con usar software de paga o software open source, pues como muchas veces ha comentado ego, en tanto la solución se ajuste al problema y lo resuelva de manera óptima para mi no hay ningún problema...

A diferencia de Casimiro para mi tanto linux, como windows o mac son muy buenos sistemas operativos, cumplen las tareas para las que fueron hechos y lo hacen bien.

Decir que Windows 2008 es una porquería solo por que tiene un costo de licenciamiento y es´producto de microsoft es, a mi parecer errado.

Casimiro Notevi

13-11-2012, 18:32:59

Vaya, hoy ha dimitido el máximo responsable de windows 8 y surface, no ha querido decir el motivo.

Al González

13-11-2012, 18:58:45

¿qué no se trataba el hilo de gratis vs paga?
Nop, este hilo se trataba de otra cosa, pero ¿ya qué? :p

Vaya, hoy ha dimitido el máximo responsable de windows 8 y surface, no ha querido decir el motivo.
No me extraña nada esa noticia...:rolleyes:
Por cierto, Casi: nuevo tema, nuevo hilo. ;)

Casimiro Notevi

13-11-2012, 19:17:56

Por cierto, Casi: nuevo tema, nuevo hilo. ;)
Me dejé llevar por la emoción :D

roman

13-11-2012, 19:32:00

ah caray... ¿qué no se trataba el hilo de gratis vs paga? y precisamente el ejemplo demuestra la buena acogida que recibe lo gratis contra lo de paga? Sin ser precisamente ese factor la clave para una buena elección de producto? Creo que andas mirando moros dónde no hay....

Realmente ya no debería explayarme en esto, pero como aludes personalmente, te diré que tus argumentos no tienen pie ni cabeza. Podría darte muchas razones por las cuáles un hilo como el de Marteens tiene más popularidad, y nada tiene que ver con que sea de paga o gratuito.

Y no. El hilo, o mejor dicho, la discusión que comenzaste, no es gratuito vs paga, sino, como ahora vuelves a decir, a si la gratuidad es o no un factor para elegir un producto. Entonces, poner de ejemplo un producto gratuito que es de sobra reconocido por su calidad, difícilmente pude tomarse como un argumento fuerte, asi como tomar un ejemplo de un producto de pago dirigido a una comunidad muy reducida también sólo con una imaginación muy amplia podría tomarse como argumento fuerte.

// Saludos

poliburro

13-11-2012, 20:03:00

Realmente ya no debería explayarme en esto, pero como aludes personalmente,

:D amigo.. no hay nada personal en esto :D es un mero intercambio de ideas.. a lo mejor de repente algo álgido el asunto pero es natural en cualquier debate :D

Y no. El hilo, o mejor dicho, la discusión que comenzaste, no es gratuito vs paga, sino, como ahora vuelves a decir, a si la gratuidad es o no un factor para elegir un producto.

es que con tantas cosas que si dijeron aquí había olvidado que el verdadero origen del debate era si Firebird soportaba o no múltiples recorsets de salida y que si no lo soportaba se añadiria a la larga lista de cosas que no soporta... Claro que eso no lo hace menos ni más al final su base de usuarios es fuerte y pujante.

Saludos...

RONPABLO

13-11-2012, 21:08:22

Ya habrán pasado unos 4 o 5 años que use MS SQL server y me fue muy útil retornar varios cursores, el XML debó decir que nunca lo use, y la conexión con bases de datos del mismo o de distinto servidor era algo que probé mucho porque me gustaba, aun así no lo hice porque tuviera la necesidad, me gustaba mucho hacer un

select campo1, campo2 from tabla

Sin necesitar que definir que campo1 era un entero y que campo2 era un varchar, aun así más de una ocación me hizo mucha falta el manejo que se da con el suspend de firebird que en MS SQL Server no se como se hace (las respuestas que recibí en el momento es que no tenía algo similar), para mis necesidades de procedimientos almacenados me parece más grabe que falte el supend que el poder retornar múltiples datasets, ya que con el mismo suspend puedo retornar datos mejor filtrados, no dudo que para otras necesidades sea mejor el tener múltiples cursores.

Respecto a lo gratis o lo de pago, pues todo depende, el hecho de descargar y usar Firebird ya se le está apoyando, y esto le produce ganancias, ahora pasar por caja no está de más, además de poner en el acerca de un "power by Firebird x.x" no está nada mal

poliburro

13-11-2012, 21:25:07

select campo1, campo2 from tabla

Sin necesitar que definir que campo1 era un entero y que campo2 era un varchar, aun así más de una ocación me hizo mucha falta el manejo que se da con el suspend de firebird que en MS SQL Server no se como se hace (las respuestas que recibí en el momento es que no tenía algo similar), para mis necesidades de procedimientos almacenados me parece más grabe que falte el supend que el poder retornar múltiples datasets, ya que con el mismo suspend puedo retornar datos mejor filtrados, no dudo que para otras necesidades sea mejor el tener múltiples cursores.

Respecto a lo gratis o lo de pago, pues todo depende, el hecho de descargar y usar Firebird ya se le está apoyando, y esto le produce ganancias, ahora pasar por caja no está de más, además de poner en el acerca de un "power by Firebird x.x" no está nada mal

Saludos amigo, qué es esa característica de suspend en firebird?

mightydragonlor

13-11-2012, 21:29:53

poliburro

13-11-2012, 21:38:34

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

13-11-2012, 22:19:32

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

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

13-11-2012, 22:48:31

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 [-] (http://clubdelphi.com/foros/#)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

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? :eek: :eek:

cointec

13-11-2012, 23:06:26

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

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? :eek: :eek:

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( :param1, :param2,..., : 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

13-11-2012, 23:38:30

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

Select *
From procedimiento( :param1, :param2,..., : 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

Select *
From procedimiento( :param1, :param2,..., : paramN )

Es exactamente lo mismo que cualquiera de estos:

CALL procedimiento( param1, param2,..., : paramN );

Exec procedimiento( param1, param2,..., : paramN );

Te devuelven todos un resulset

RONPABLO

13-11-2012, 23:56:37

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:
select valor from SP_CADENA_A_RECORD('1,3,4,6,8,12')
Por ejemplo le puedo hacer un join con una tabla

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

RONPABLO

14-11-2012, 00:06:10

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 [-] (http://www.clubdelphi.com/foros/#) Select * From procedimiento( : Param1, : Param2,..., : paramN )

Es exactamente lo mismo que cualquiera de estos:

Código SQL [-] (http://www.clubdelphi.com/foros/#) 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

poliburro

14-11-2012, 00:25:51

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? :eek: :eek: :eek: :eek: 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?

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:select * from (Select 'Data' As Dummyfield) TableDummyInner join Table on 1 = 1

Casimiro Notevi

14-11-2012, 00:51:11

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

poliburro

14-11-2012, 01:00:07

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

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

Casimiro Notevi

14-11-2012, 01:50:10

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 :eek::eek::eek:", "pero firebird no tiene laotracosa :eek::eek::eek:", 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 :eek::eek::eek:".
Cuando realmente es que no lo has entendido, o no se te ha explicado bien.

RONPABLO

14-11-2012, 03:08:25

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.

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? :eek: :eek: :eek: :eek: 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

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

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

Sí.

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:

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:

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

14-11-2012, 03:47:48

Bueno, este documento (http://www.firebird.com.mx/imagenes/descargas/procedimientos_almacenados.pdf) explica un poco sobre los procedimientos almacenados, es viejo y trata de Interbase, pero para este caso, acplica, este otro (http://www.firebird.com.mx/descargas/documentos/tema_6_-_psql.pdf) es algo mas actual y muestra mas cosas.

Saludos.

poliburro

14-11-2012, 04:18:32

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 :eek::eek::eek:", "pero firebird no tiene laotracosa ", etc.

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? :eek: :eek: :eek:

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

cointec

14-11-2012, 08:18:17

Al González

14-11-2012, 09:06:09

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.

mightydragonlor

14-11-2012, 16:05:06

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.

roman

14-11-2012, 16:11:18

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

14-11-2012, 16:27:02

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?

Casimiro Notevi

14-11-2012, 16:43:18

Nunca he logrado entender pro que les es tan dificil reconocer que firebird no es un buen motor por el contrario es un motor medianon que puede ser una buena alternativa para desarrollos pequeños pero comparado con el trabajo que hacen verdaderos motores de bases de datos su rendimiento es más bien mediocre.
Enlace (http://www.clubdelphi.com/foros/showthread.php?t=66618&highlight=paradox)
Incluso lo equiparas a paradox, access y dbase :confused:
Adolecer de estas características no la hacen un mal motor, al contrario sigue siendo una excelente opción para nuestros desarrollos, tanto como lo es access o paradox o dbase. Pero aceptando que tiene limitantes no deberia compararse con los grandes. (Oracle, Postgress, MsSql,Db2, Informix)
Enlace (http://www.delphiaccess.com/forum/firebird-4/firebird-2-5-rc-2/)

En fin, no vale la pena, está bien que creas lo que quieras creer, amigo poliburro, pero no nos cuentes "cosas" que no son, porque las palabras se las lleva el viento, pero lo escrito... escrito está.

poliburro

14-11-2012, 16:49:31

Enlace (http://www.clubdelphi.com/foros/showthread.php?t=66618&highlight=paradox)
Incluso lo equiparas a paradox, access y dbase :confused:

Enlace (http://www.delphiaccess.com/forum/firebird-4/firebird-2-5-rc-2/)

En fin, no vale la pena, está bien que creas lo que quieras creer, amigo poliburro, pero no nos cuentes "cosas" que no son, porque las palabras se las lleva el viento, pero lo escrito... escrito está.

¿Cosas que no son? ¿Cuándo he dicho que me gusta? al contrario desde el inicio de este hilo dije "si no lo sporta se agrega a la larga lista de cosas que no soporta". y lo acabo de decir hace un momento. Firebird no me gusta Por que se toman tan a personal una crítica a firebird? por qué les cuesta tanto aceptar las críticas contra ese motor? deberían ser tan faciles de aceptar como las que hacen contra otras tecnologias....

mightydragonlor

14-11-2012, 16:59:45

¿Cosas que no son? ¿Cuándo he dicho que me gusta? al contrario desde el inicio de este hilo dije "si no lo sporta se agrega a la larga lista de cosas que no soporta". y lo acabo de decir hace un momento. Firebird no me gusta Por que se toman tan a personal una crítica a firebird? por qué les cuesta tanto aceptar las críticas contra ese motor? deberían ser tan faciles de aceptar como las que hacen contra otras tecnologias....
Creo que mas que las críticas que haces al Firebird es la forma que tomas todo, como las preguntas que hiciste repecto a los procedimientos, sacando conclusiones que no son lógicas, en forma de pregunta reitero, algo como entonces no tiene plan de ejecución? y cosas por el estilo.

Si bien Firebird carece de ciertas caracteristicas, como este caso, multiples resulsets, no quiere decir que estos no se puedan solventar de diferentes formas, varios procedimientos almacenados para este caso, soporte XML, hay varias UDF´s que hacen esto, lo mismo para búsqueda de texto completo, que de hecho no son soportadas directamente en la Api de MySQL, si no que son plugins adicionales que aunque ya vengan con la instalación, vienen a ser lo mismo que las UDF's de Firebird, y así varias características que pueden ser solventadas facilmente por programación, es mas sé de varias funciones que añaden soporte XML a Firebird, sin pasar por una UDF.

Saludos.

RONPABLO

14-11-2012, 17:02:51

3- He visto aquí a muchos vosciferar contra .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?

Para mi es normal, todos en la vida tenemos cosas que no nos gustan, aun así Firebird hace cosas que SQL Server no hace, como hay cosas que Firebird no hace, ¿es normal no?.

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?

Imagina que en un llamado a un procedimiento se trae 3 DataSets, uno es encuestas, el segundo es preguntas de la encuesta y el tercer DataSet trae las respuestas dadas a cada pregunta, se trae únicamente los datos que se van a usar para no sobrecargar la conexión a red, estos DataSet en .Net se pueden tomar como tablas en memoria y hacer una especie de maestro detalle donde al seleccionar en un grid una de las encuestas me muestre en otro las preguntas ofrecidas y el total de respuestas por preguntas en otro grid,

RONPABLO

14-11-2012, 17:10:13

Por que se toman tan a personal una crítica a firebird? por qué les cuesta tanto aceptar las críticas contra ese motor? deberían ser tan faciles de aceptar como las que hacen contra otras tecnologias....
Tal vez por la misma razón que tu te empeñas en decir que SQL Server puede hacer de otra forma lo que firibird hace, osea le quitas importancia a las ventajas de firebird sobre SQL Server porque lo puedes hacer de otra forma, lo mismo me pasa a mi, le quito importancia a que no pueda tener varios ResulSets en firebird porque lo puedo hacer de otra forma y generalmente realizando la misma cantidad de trabajo, a veces un poco más a veces un poco menos.

poliburro

14-11-2012, 17:28:05

Tal vez por la misma razón que tu te empeñas en decir que SQL Server puede hacer de otra forma lo

Pero no solo he mencionado a SQL server, también he mencionado a mysql, postgresql, oracle y db2 que son los motores de bases de datos que utilizo.....

Insisto... como lo mencioné en un hilo que cita casimiro.

Adolecer de estas características no la hacen un mal motor, al contrario sigue siendo una excelente opción para nuestros desarrollos, tanto como lo es access o paradox o dbase. Pero aceptando que tiene limitantes no deberia compararse con los grandes. (Oracle, Postgress, MsSql,Db2, Informix)

Firebird no es malo. al contrario es una excelente opción como lo pueden ser otros motores como access o paradox o dbase o mysql, pero eso de equipararlo a cualquiera de los grandes me parece una necedad.

Claro ese es mi punto de vista... no es la verdad absoluta. Como ha querido desde un inicio hacerlo ver aquí Casimiro tergiversando mis comentarios... o en el colmo de la censura Al gonzalez acusandome de tener una "actitud inquina" contra Firebird. como si para una crítica fuera necesario sentir simpatia por el objeto de las críticas...

roman

14-11-2012, 17:37:03

P
Imagina que en un llamado a un procedimiento se trae 3 DataSets, uno es encuestas, el segundo es preguntas de la encuesta y el tercer DataSet trae las respuestas dadas a cada pregunta, se trae únicamente los datos que se van a usar para no sobrecargar la conexión a red, estos DataSet en .Net se pueden tomar como tablas en memoria y hacer una especie de maestro detalle donde al seleccionar en un grid una de las encuestas me muestre en otro las preguntas ofrecidas y el total de respuestas por preguntas en otro grid,

Mmm. Creo que ahora lo veo más claro. Usar joins ocasionaría el viaje de datos repetidos del servidor al cliente.

Gracias :)

// Saludos

roman

14-11-2012, 17:39:52

o en el colmo de la censura

Nada más para aclarar a quienes en un futuro pudieran leer este desafortunado comentario. No ha habido ni mucha ni poca censura en este hilo, como no la hay en el Club en general.

// Saludos

poliburro

14-11-2012, 17:43:07

Nada más para aclarar a quienes en un futuro pudieran leer este desafortunado comentario. No ha habido ni mucha ni poca censura en este hilo, como no la hay en el Club en general.

// Saludos

No fué hacia Club Delphi como tal... sino a Al en particular... Aquí, el sitio como tal nunca me ha censurado. Aclaro mi desafortunado comentario....

Casimiro Notevi

14-11-2012, 17:49:05

Como ha querido desde un inicio hacerlo ver aquí Casimiro tergiversando mis comentarios...

¿Qué comentarios he tergiversado? :confused:

roman

14-11-2012, 17:49:07

Bueno, en lo personal, tampoco pienso que Al haya manifestado ningún tipo de censura.

De todas formas, propongo que no sigamos enfrascándonos en un debate en el que cada cual tiene sus posiciones muy asentadas e inamovibles.

// Saludos

ecfisa

14-11-2012, 17:50:09

Firebird no es malo. al contrario es una excelente opción como lo pueden ser otros motores como access o paradox o dbase o mysql, pero eso de equipararlo a cualquiera de los grandes me parece una necedad.

Hola.

Estoy de acuerdo, Firebird o MySQL no son rivales para, por ejemplo, un Oracle.

Pero personalmente opino que poner en el mismo plano a Firebird o MySQL con Paradox, DBase o Access es también un despropósito.

Saludos.

poliburro

14-11-2012, 17:56:17

¿Qué comentarios he tergiversado? :confused:

por ejemplo aquí: http://clubdelphi.com/foros/showpost.php?p=449087&postcount=41

o aquí: http://clubdelphi.com/foros/showpost.php?p=449092&postcount=45

o aquí http://clubdelphi.com/foros/showpost.php?p=448979&postcount=7 cuando en realidad el que lo comenzó fuiste tu aquí http://clubdelphi.com/foros/showpost.php?p=448973&postcount=4 a pesar de que aclaré que no quería debatir aquí: http://clubdelphi.com/foros/showpost.php?p=448975&postcount=6 aclarando que no me gusta firebird y a pesar de ello me acusas de incongruente aquí : http://clubdelphi.com/foros/showpost.php?p=449450&postcount=117

RONPABLO

14-11-2012, 17:58:00

Pero no solo he mencionado a SQL server, también he mencionado a mysql, postgresql, oracle y db2 que son los motores de bases de datos que utilizo.....

Insisto... como lo mencioné en un hilo que cita casimiro.

[/i]

Firebird no es malo. al contrario es una excelente opción como lo pueden ser otros motores como access o paradox o dbase o mysql, pero eso de equipararlo a cualquiera de los grandes me parece una necedad.

Claro ese es mi punto de vista... no es la verdad absoluta. Como ha querido desde un inicio hacerlo ver aquí Casimiro tergiversando mis comentarios... o en el colmo de la censura Al gonzalez acusandome de tener una "actitud inquina" contra Firebird. como si para una crítica fuera necesario sentir simpatia por el objeto de las críticas...

Claro y has defendido los procedimientos almacenados MySQL cosa que una gran cantidad se queja, yo personalmente empece a usar firbird después de pasar de Paradox a MySQL, y dicho paso fue desastroso, trabajaba más lento las mismas instrucciones en MySQL que en Paradox, comía más recursos y para rematar en ese momento la integridad referencial solo se podía en una arquitectura y al pasarnos a dicha arquitectura fue aun más lenta las cosas, ya no hablar de procedimientos almacenados o disparadores que no tenía en ese momento, después de mucho probar y probar abandonamos la idea de MySQL y nos pasamos a Firebird y y para mis necesidades que eran mayores a las de un Paradox o un Excel fue genial, unos años después por otro proyecto nos toco trabajar en MS SQL Server y personalmente me acuerdo que en ese tiempo decía "lo único que me gusta de MS es SQL Server y Age Of Empires", hoy en día también me gusta algo el C#... Ahora regresando al punto muy probablemente vas a querer ver que cosas hacía yo para que me fuera más mal con MySQL que con Paradox a tal punto que lo aborrecí y muy probablemente pensarás que hice las cosas muy mal para llegar a decir que MySQL era extramadamente lento, pues es eso, cuando dices algo sobre Firebird y lo dices con gente que trabaja con él todo él día pensarán que tus apreciaciones son más subjetivas que basadas en hechos, ya que las cosas que le criticas son cosas que hemos aprendido a manejar de otra forma, y como digo yo cuando trabajé con MS SQL Server extrañé mucho el uso del Suspend de firebird y ahora retomando este hilo también el no poder usar los procedimientos almacenados como consultas es algo que para mi es un punto muy malo de SQL Server ya que es demasiado útil, pero como no lo has usado no notas lo importante que es.

poliburro

14-11-2012, 17:58:10

Hola.

Pero personalmente opino que poner en el mismo plano a Firebird o MySQL con Paradox, DBase o Access es también un despropósito.

Saludos.

En esto estoy deacuerdo, probablemente he caido en la exageración al mencionarlo junto con paradox o dbase o access. Podríamos decir que está entonces en un punto intermedio entre los grandes y los pequeños?

Al González

14-11-2012, 18:05:31

Román, poliburro ya había aclarado el asunto de los datos repetidos. :)
Siguiendo el ejemplo que he posteado en mi blog, si tienes las tablas de encabezado de venta, detalle de venta e información de clientes. devolver toda esa información como un solo join normalito te genera una tabla con la siguiente estructura:

filasdatoscliente, datosencabezadoventa, partidadeventa1
filasdatoscliente, datosencabezadoventa, partidadeventa2
filasdatoscliente, datosencabezadoventa, partidadeventa3
...........
filasdatoscliente, datosencabezadoventa, partidadeventaN

como puedes observar, hacer uso de joins para devolverver toda esa información agrupada es sumamente infeciente pues vas a devolver un recordset con información duplicada y que te exigirá seprarla en tu código para mostrarla en los diferentes repositorios.

Casi, ya no recordaba aquellas opiniones que citaste de nuestro compañero (creo que ya no tengo memoria para ciertas cosas).

Edgar, aunque pudiera, eliminar la referencia no tendría ningún sentido. Además no cambia mi deseo de que visiten tu bitácora, yo encuentro valiosa la información que ahí compartes. ^\||/

En cuanto a la sorprendente acusación de censura, pues ni qué decir. :(

roman

14-11-2012, 18:08:29

Román, poliburro ya había aclarado el asunto de los datos repetidos. :)

Sí, tienes razón. Y no culpo a poliburro, sino a mi mismo :) Por alguna razón, no fue sino hasta que leí el comentario de RONPABLO que cai en la cuenta.

// Saludos

poliburro

14-11-2012, 18:09:29

ahora retomando este hilo también el no poder usar los procedimientos almacenados como consultas es algo que para mi es un punto muy malo de SQL Server ya que es demasiado útil, pero como no lo has usado no notas lo importante que es.

esto es cierto... nunca he usado procedimientos almacenados como consultas. :) no puedo opinar sobre su utilidad o inutilidad.

sobre mysql... pues ahí si creo que dependen muchos factores. Diseño de la base de datos, tuning, hardware, etc..

tengo un sistema funcionando en línea con múltiples usuarios dode una de las tablas que consulto con dos millones de registros me responde en décimas de segundos. A mi me ha funciondo muy bien y estoy a gusto aunque me guste más trabajr en Oracle o Db2 o PostgreSql, mysql cumple las funciones que le doy muy bien...

poliburro

14-11-2012, 18:19:38

Edgar, aunque pudiera, eliminar la referencia no tendría ningún sentido. Además no cambia mi deseo de que visiten tu bitácora, yo encuentro valiosa la información que ahí compartes.

En cuanto a la sorprendente acusación de censura, pues ni qué decir.

Amigo, esa fué precisamente mi percepción a lo que mencionaste sobre mi actitud con relación a firebird. De ahí que te dijera que si lo considerabas a bien podrías eliminar la referencia a mi artículo. Si estoy errado en la percepción retiro lo dicho.

ecfisa

14-11-2012, 18:20:58

En esto estoy deacuerdo, probablemente he caido en la exageración al mencionarlo junto con paradox o dbase o access. Podríamos decir que está entonces en un punto intermedio entre los grandes y los pequeños?
Desde mi humilde opinión, es el segmento donde los ubicaría.

Saludos.

RONPABLO

14-11-2012, 18:23:03

esto es cierto... nunca he usado procedimientos almacenados como consultas. :) no puedo opinar sobre su utilidad o inutilidad.

sobre mysql... pues ahí si creo que dependen muchos factores. Diseño de la base de datos, tuning, hardware, etc..

tengo un sistema funcionando en línea con múltiples usuarios dode una de las tablas que consulto con dos millones de registros me responde en décimas de segundos. A mi me ha funciondo muy bien y estoy a gusto aunque me guste más trabajr en Oracle o Db2 o PostgreSql, mysql cumple las funciones que le doy muy bien...

La aplicación que en su momento estuvo potenciada por MySQL hoy en día está en clientes que han llegado a tener más de 2 millones de registros en una tabla de control asistencia de citas, al ver las citas de un día no se nota ni el pestañeo y es muy poco lo que he cambiado de código ahora que usa Firebird a cuando usó MySQL y en ese momento con nuestros primeros clientes "grandes" y con unos 100mil registros se llegó a demorar 15 segundos y es un punto crítico... personalmente creo que hice muchas cosas malas para que se demorará tanto tiempo.

poliburro

14-11-2012, 18:32:30

personalmente creo que hice muchas cosas malas para que se demorará tanto tiempo.

más que cosas malas tiene que ver con la parte de "tuning" y aprovechamiento de las fascilidadades del motor. supongo que al conocer mejor firebird aprovechaste sus características y al conocer un poco menos mysql desaprovechaste algunas de las que tiene... En lo personal me gusta mucho trabajar en bases de datos, de hecho aspiro a ser un día DBA más que programador, aunque claro, programar es algo que también me apasiona :)

Casimiro Notevi

14-11-2012, 18:58:45

Bueno, amigo, yo no veo que haya tergiversado nada, pero si lo crees así, lo lamento.

cointec

15-11-2012, 14:50:47

La aplicación que en su momento estuvo potenciada por MySQL hoy en día está en clientes que han llegado a tener más de 2 millones de registros en una tabla de control asistencia de citas, al ver las citas de un día no se nota ni el pestañeo y es muy poco lo que he cambiado de código ahora que usa Firebird a cuando usó MySQL y en ese momento con nuestros primeros clientes "grandes" y con unos 100mil registros se llegó a demorar 15 segundos y es un punto crítico... personalmente creo que hice muchas cosas malas para que se demorará tanto tiempo.

Hola, nosotros tenemos tablas con 60 o más millones de registros y el acceso a ellas es rápido, por lo que no creo que el problema dependa de firebird. Si tarda 15 segundos, no está utilizando índices. Creo que deberías revisar el plan de ejecución de las consultas.

maeyanes

15-11-2012, 16:06:58

Hola...

Hola, nosotros tenemos tablas con 60 o más millones de registros y el acceso a ellas es rápido, por lo que no creo que el problema dependa de firebird. Si tarda 15 segundos, no está utilizando índices. Creo que deberías revisar el plan de ejecución de las consultas.

Creo que te confundiste, RONPABLO estaba hablando de MySQL y no de Firebird cuando se refería a que era lento.

Saludos...

RONPABLO

16-11-2012, 05:37:09

Hola...

Creo que te confundiste, RONPABLO estaba hablando de MySQL y no de Firebird cuando se refería a que era lento.

Saludos...

Aja, además terminé diciendo que en ese tiempo (hace mucho), debí estar haciendo las cosas muy mal para tener esos resultados de tanta lentitud, creo que algo que mejoro la velocidad era que en ese momento en MySQL la integridad referencial no estaba muy bien implementada, cosa que de entrada en FIribird si que soportaba sin problemas, y aunque un una llave foránea no crea indices si mejora (percepción personal) la velocidad, algo similar a la indexación debe de hacer al crear dicha llave pienso yo

Casimiro Notevi

16-11-2012, 09:57:48

Claro, al crear una clave foránea se crea automáticamente un índice por ese campo.

mightydragonlor

16-11-2012, 17:53:57

y aunque un una llave foránea no crea indices si mejora (percepción personal) la velocidad, algo similar a la indexación debe de hacer al crear dicha llave pienso yo

Realmente no es así, si bien los índices son necesarios para optimizar el rendimiento, las llave foráneas hacen que sea mas lento, es decir, el motor tiene que comprobar que esa llave se cumpla, por esta razón una base de datos sin llaves foráneas da como resultado una mejora notable en velocidad, eso si, no tiene sentido usar un RDBMS si no le vas a sacar provecho, además que las claves foráneas son super importantes para mantener la integridad de la base de datos.

No hace mucho, una empresa consultora muy importante, asesoró a una empresa para la cual hacemos desarrollos, y una de las cosas que les dijo, es esto que les comento para una base de datos oracle 11g, algo que obviamente no estoy desacuerdo por lo antes mencionado.

Saludos.

Casimiro Notevi

16-11-2012, 18:26:14

Bueno, todo es relativo, lo más "rápido" es no tener triggers, stored procedures, claves foráneas, sólo un índice para buscar sobre el mismo, etc.
Cuantos más índices tengamos entonces más lento será porque tiene que actualizarlos todos, y así ocurre con todo, pero entonces tendriamos una tabla plana y punto.

mightydragonlor

16-11-2012, 18:32:36

Casimiro Notevi

16-11-2012, 19:26:53

exacto ^\||/

Gallosuarez

16-11-2012, 20:01:30

Bueno, hasta para eso (agilizar algunas actualizaciones masivas e inserciones complejas sin utilizar índices) Firebird cuenta con el no tan conocido RDB$DB_KEY. Es una verdadera lástima que Claudio Valderrama, que hizo mucha de la investigación sobre este tema haya dado de baja su página web (http://www.cvalde.net/document/practical_use_of_the_rdb.htm). Sería bueno saber si alguien conserva alguna copia sobre todo esa investigación o en su defecto pedirle de favor a Claudio Valderra si puede proporcionar todo es información nuevamente.

Saludos,
Gerardo Suárez Trejo

roman

16-11-2012, 20:13:30

¡Ah! Pues para eso existe wayback machine (http://web.archive.org/web/20090103043321/http://www.cvalde.net/document/practical_use_of_the_rdb.htm) :)

// Saludos

Gallosuarez

16-11-2012, 20:34:55

Roman:

Bueno, pues asunto solucionado. Gracias por el aporte ...
Por otro lado, como bien lo dice dicho artículo, los ejemplos pudieran ser escritos mas en forma de un "tutorial", de esta manera se ejemplifica mas su entendimiento.

Saludos,
Gerardo Suárez Trejo

jachguate

16-11-2012, 21:04:07

Hola!!

Recién estoy leyendo este largo hilo, por lo que no estoy enterado de todo su contenido aún :eek:

A medida que voy leyendo, y dado que he salido a bailar entre los mensajes, he encontrado un par de referencias que me gustaría comentar:

mientras que jachguate hace mucho tiempo que no se pasa por aquí y ni siquiera comenzó él el hilo.
...
Y tan apreciamos lo que jachguate dio en su momento al club, que sigue siendo moderador.

A la fecha sigo considerando al Club Delphi mi casa, o para ser más exacto, algo así como la casa de mis padres, de la cuál estoy separado por varios cientos de kilómetros de distancia y de igual manera visito poco, pero siempre que lo hago, lo hago con toda la confianza, sintiéndome tan bienvenido como siempre.

La decisión del equipo de mantener mi status de moderador es algo que también aprecio y agradezco, aunque no con poca pena, pues para nada realizo las funciones y tareas que los moderadores hacen para mantener la casa en orden y con buen funcionamiento.

Simplemente diré, que, más que defender un punto, da la impresión de que tienen cierto rencor por no haber visto aquí una recepción más abultada a la traducción del libro de Programación Paralela, un rencor, que ni siquiera sé si el propio Juan Antonio tiene.

Sobre esto, mi estimado roman, no comprendo exactamente a que te refieres, pero lejos de un rencor, lo que existe de mi parte es agradecimiento, a quien se tomó la molestia de publicar la noticia de la publicación del libro, y a los moderadores del club por permitir el espacio para que esta se realizara y permaneciera.

De entrada sé que el tema es bastante especializado y por tanto no genera demasiado movimiento a su alrededor –aunque dicho sea de paso, multi-hilos es el presente y el futuro de la computación–, además de que, debido a la falta de costumbre encontrar libros en español sobre Delphi, poco estamos acostumbrados a leer y dar la bienvenida a este tipo de materiales.

Un saludo cordial!