¿Para que BlackFishSQL?

[[Al González]]

¡Hola a todos!

Empezado por jhonny

Ya veo, gracias Sinaloense ... de todas formas insisto desde aqui con lo del Driver DBX para FireBird, pa ver si de pronto CodeGear toma este comentario en cuenta .

A mí también me gustaría que existiera. Actualmente trabajo con dbExpress (DBX) y Firebird sin problema alguno, pero porque estoy todavía con Firebird 1.5, la cual es más que suficiente para la mayoría de mis desarrollos (la 2 no la tocaría hasta que se perciba buena presencia en el mercado, tiene muy poco tiempo).

Pero no es responsabilidad de CodeGear crear un controlador dbExpress para cada base de datos que exista. Aunque sí sería estratégico que atendiera a las que son más populares, como Firebird. El problema de ésta es que compite directamente con su base de datos estrella: InterBase. Y por una simple deducción lógico-económica no han querido hacerlo.

No sabía que existiera un sólo controlador dbExpress para Firebird y que además fuese de paga. ¿Estás seguro de lo que dices Sinaloense? ¿No habrá otro por ahí escondido que sea gratuito?

Del blog citado por Eliseo, me quedo con el comentario de Steve Shaughnessy, donde menciona la capacidad del controlador DBXClient (controlador dbExpress para Blackfish SQL y abierto a cualquier otra base de datos que en el futuro soporte también "JSON based streaming protocol") de transmitir campos BLObs segmentados y de los, por así llamarlos, parámetros opcionales (si no pones un parámetro en la llamada a un procedimiento almacenado, DBXClient lo pone por ti, es como lo entiendo, así al agregar un nuevo parámetro a un procedimiento, las aplicaciones cliente seguirán trabajando sin problemas, quiero pensar).

...Today only the Blackfish SQL for windows and Blackfish SQL for Java support this protocol...

Quiero pensar que otras base de datos, como Firebird, sí cuentan también con el envío segmentado de BLObs y meta datos de parámetros (de hecho esto último me consta que sí existe en Firebird). Pero la diferencia está en el controlador, no en la base de datos. Es decir, las únicas dos ventajas reales y actuales que logro percibir de Blackfish SQL es que es 100% .NET (ventaja para algún servidor o aplicación que requiera una base de datos que no esté atada a código máquina ) y que ya tiene un controlador que le soporta eficientemente el asunto de los BLObs segmentados y los meta datos de parámetros (para hacer parámetros opcionales, donde al no especificar uno, supongo lo toma como "Null").

No sé que opinan ustedes, pero de momento todavía no le veo mucho peso al producto. Lo más probable es que sea por mi ignorancia al respecto. Ninguna compañía dedica demasiado tiempo a un producto sin apostarle a que ese producto tendrá algo muy bueno encima de la competencia. ¿Qué será?

Un abrazo debatido.

Al González.

[jhonny]

Empezado por Al González

No sé que opinan ustedes, pero de momento todavía no le veo mucho peso al producto. Lo más probable es que sea por mi ignorancia al respecto. Ninguna compañía dedica demasiado tiempo a un producto sin apostarle a que ese producto tendrá algo muy bueno encima de la competencia. ¿Qué será?

Exacto, es precisamente esa la duda que me llevo a iniciar este debate, por un lado no se le ve mucho peso al producto, pero por otro lado y retomando un poco tus palabras, una compañia no apostaria tanto tiempo y dinero, en un proyecto destinado al fracaso, asi que por eso debe tener algo especial que la haga competir con las demas.

[Nasca]

En java hay algunos servidores en la línea de este. Servidores java que se pueden integrar fácilmente en las aplicaciones. Pueden ser prácticos en ocasiones, aunque el modo embebido de Firebird puede resolver casi esas mismas situaciones.

No recuerdo los nombre pero sin ir muy lejos uno de ellos es el motor que hay detrás de las bases de datos en OpenOffice.org y otro lo liberó la propia IBM (si no recuerdo mal).

Creo que se va a por ese segmento de servidor embebible y completamente compatible con los grandes servidores con los que no podrá competir en volumen de información manejado y velocidad.

Otra duda que me surge. Igual que hay un controlador totalmente java para firebird que no depende de código nativo se podría montar una librería cliente completa en C# (no se si la hay ya). Eso seguramente evitaría el problema de PInvoke. Al fin y al cabo el servidor nos da igual como corra, no es un cuestión que nos tenga que preocupar salvo que lo queramos integrar dentro de la propia aplicación. Creo que no van por ahí los tiros, pero bueno, son pareceres de un novato.