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

Leyendo este artículo de nuestro compañero poliburro (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.

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

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

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

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

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.

Hombre, has empezado tú ;)

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

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

¿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

Código SQL [-]
 
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?

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.

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

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

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.

¿y esto lo basas en?

Aquí 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... :)

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.

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.

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

enlace

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.

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

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

y de Sql server dice lo siguiente al respecto:

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.

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

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

¿yo he dicho que no son comparables posgreSql y MsSql? ah caray ¿dónde?.

Cuándo se tratan datos duros y fidedignos eso no es verdad.

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

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.

Precisamente, amigo poliburro, las pruebas de comparaciones son para el resto de los x millones de personas que no lo han podido testear personalmente.

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.

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.

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:

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

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

// Saludos

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

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

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.

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.

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

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

// Saludos

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

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.

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.

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.

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?

No recuerdo haber dicho eso, lo que he dicho es que windows no es una solución seria y profesional.

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

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