Transacciones en Zeos. Conviene una por Conexión ?

[[mightydragonlor]]

Yo personalmente uso ReadCommited, no me ha presentado ningún problema, por el momento, además que también las transacciones las manejo directamente en los SP's, ya que a la base de datos pueden acceder diversos aplicativos, no sólo los que yo haga en Lazarus, sino Servicos Web y Páginas Web, en diferentes lenguajes, así que de esta forma me aseguro que todo se haga en una única transacción, especialmente cuando se intervienen varias tablas en una única llamada a un SP, por lo demás no veo ningún problema, es verdad que Zeos es el mas lento de los componentes de acceso a datos, pero no es algo que puedas medir en la experiencia de usuario, bueno, si, pero sólo si un usuario está haciendo miles de transacciones por segundo, lo notará, de resto no.

Saludos.

[rolandoj]

Empezado por mightydragonlor

Yo personalmente uso ReadCommited, no me ha presentado ningún problema, por el momento, además que también las transacciones las manejo directamente en los SP's, ya que a la base de datos pueden acceder diversos aplicativos, no sólo los que yo haga en Lazarus, sino Servicos Web y Páginas Web, en diferentes lenguajes, así que de esta forma me aseguro que todo se haga en una única transacción, especialmente cuando se intervienen varias tablas en una única llamada a un SP, por lo demás no veo ningún problema, es verdad que Zeos es el mas lento de los componentes de acceso a datos, pero no es algo que puedas medir en la experiencia de usuario, bueno, si, pero sólo si un usuario está haciendo miles de transacciones por segundo, lo notará, de resto no.

Saludos.

Hola,

Gracias por el comentario. Aunque no es de este hilo, creo que vale pena anotar algo acerca del uso de los Stored Procedures (SP), o procedimientos almacenados, para evitar malos entendidos respecto a otros conceptos discutidos aquí

En tú caso, la ventaja no es, como anotas, asegurarse que todo se haga en una sola transacción. Eso igual puede garantizarse desde lenguajes de programación, con o sin SPs. La ventaja, dependiendo del modelo de acceso (ahora lo aclaro), es codificar una sola vez, ya que el código de los SPs lo puedes llamar desde cualquiera de los lenguajes de programación a los que te refieres. Si no se trabajara así, podría ser necesario hacer la codificación de un mismo proceso en más de un lenguaje de programación.

Ahora, cuando hablo del modelo de acceso me refiero a si un programa accede a tú Base de Datos vía servicio Web, o si lo hace con conexión directa a la Base de Datos desde un equipo cliente. En el segundo caso, si algunos de tús aplicativos trabajan así, entonces si te es clave usar los procedimiento almacenados porque en ese modelo no se permite que otros lenguajes usen el código del servdor ya que este está entremezclado con el del equipo cliente.

Mi caso es diferente. Yo uso muy rara vez procedimientos almacenados porque para mi es clave la portabilidad de motores de Base de Datos (y si los uso, debo tener también disponible una versión alternativa sin ellos). La ventaja mayor que obtengo con los SP es de rendimiento; por ello los uso solo cuando mi codificación normal está dando malos tiempos de respuesta.

Los SPs no son portables porque cada motor tiene su propio lenguaje. Eso es una desventaja inaceptable en mi caso porque, como dije, me es muy importante que los clientes puedan elegir un motor de Base de Datos, entre un grupo lo más grande posible de motores disponibles. Así, cuando uso SPs, de todas maneras dejo una versión sin SPs para poder cambiar facilmente de motor si fuere requerido.

En el modelo Web. dado que no hay un equipo cliente conectandose directamente al motor, puede trabajarse usando cualquier lenguaje en el lado servidor y aún así soportar múltiples lenguajes del lado del cliente. Eso si, para ello, hay que usar el siguiente flujo de datos :

a. Petición enviada desde el cliente, mediante un protocolo y en forma de una cadena de texto
b. Decodificar los parámetros de la cadena
c. Efectuar las operaciones indicadas en la petición y, si es del caso, devolver una respuesta "pura" (eso es solo datos que se hubiesen generado)
d. Formatear la respuesta según el lenguaje que la pida (esta es la parte clave porque si es para desplegar páginas Web el texto varía según el lenguaje)
e. Devolver el resultado al cliente

Por eficiencia (evitar análisis del lenguaje de programación a tiempo de ejecución), lo mejor es encapsular en librerías (que serían realmente las compartidas), la lógica de negocios del punto c. (y probablemente también el punto b.)

De esa forma, se presenta un font-end de acceso a las librerías, que se codificaría distinto para cada lenguaje que requiera el servicio.

Aún se puede optimizar más; pero, ya esto parece curso de programación y nos alejamos del tema, así que mejor lo dejamos hasta aquí. Solo quise hacer la aclaración para evitar malos entendidos respecto a los SPs

Para finalizar, me preocupa lo que dices de que Zeos es el más lento de las tecnologías de acceso. Hay un hilo de discusión al respecto?

[Casimiro Notevi]

Empezado por rolandoj

Para finalizar, me preocupa lo que dices de que Zeos es el más lento de las tecnologías de acceso. Hay un hilo de discusión al respecto?

Sí que lo hay, se ha comentado en diversas ocasiones, aunque lo más a mano que tengo es esta comparativa del que hice un pdf.

También puedes ver este hilo.

[rolandoj]

Empezado por Casimiro Notevi

Sí que lo hay, se ha comentado en diversas ocasiones, aunque lo más a mano que tengo es esta comparativa del que hice un pdf.

También puedes ver este hilo.

Hola Casimiro,

Gracias por el dato. Resulta interesante leer esa documentación.

Más allá de las obvias limitaciones de las pruebas, comentadas en ese hilo, me llama la atención la diferencia de Zeos con las otras tecnologías que soportan múltiples motores (no incluyo a las que solo trabajan con Interbase/Firebird porque es obvio que tenían que ser más rápidas).

El caso es que esa prueba muestra a Zeos como 4 veces más lento que dbExpress. Eso es preocupante y habría que hacer más pruebas para confirmar rendimientos. Es que incluso es el doble de la criticada BDE.

Bueno, como dije antes, creo que ya toca ponerse a probar de a poco.

Saludos

[[mightydragonlor]]

Empezado por rolandoj

Hola Casimiro,

Gracias por el dato. Resulta interesante leer esa documentación.

Más allá de las obvias limitaciones de las pruebas, comentadas en ese hilo, me llama la atención la diferencia de Zeos con las otras tecnologías que soportan múltiples motores (no incluyo a las que solo trabajan con Interbase/Firebird porque es obvio que tenían que ser más rápidas).

El caso es que esa prueba muestra a Zeos como 4 veces más lento que dbExpress. Eso es preocupante y habría que hacer más pruebas para confirmar rendimientos. Es que incluso es el doble de la criticada BDE.

Bueno, como dije antes, creo que ya toca ponerse a probar de a poco.

Saludos

Como dije antes, esto no se nota, a menos que hagas transacciones intensivas, de mas de 10.000, además, ZEOS tiene que hacer Parser de todas las consultas para identificar si es correcta o no, a parte de las múltiples interfaces a los diversos motores, cosa que ADO y BDE no hacen, por otro lado ZConnection1.ExecuteDirect(), ejecuta una instrucción SQL sin pasar por todo el proceso y es por mucho mas rápida a las normales, así que siempre tienes la opción, dependiendo del proceso que hagas, como en vez de generar 1000 inserts con 1000 commits, generas un sólo commit para los 1000 inserts y podrás ver una diferencia grande en desempeño.

Saludos.