Muchas conecciones o una sola???

[pkbza]

Hola foro
Tengo algun tiempo trabajando con Delphi, lo que aprendi con respecto a las coneccion es al servidor de BD (MySQL o Interbase), es que con 1 SQLConecction en un formulario principal y unos SQLQuerys en los formularios que necesitan trabajar con datos me bastaba, para cada consulta (sea de edicion o recogida de datos) me conectaba al servidor, ejecutaba la consulta, rescataba o editaba la(s) tabla(s) correspondiente(s), asignaba los datos a variables o componentes (cuando eran consultas de recogida) y luego me desconectaba. Si tenia que actualizar varias tablas me conectaba, iniciaba la transaccion, editaba las tablas, cerraba la transaccion y luego me desconectaba. De esa forma trabajo actualmente, pero desde hace algun tiempo trabajo con un programador que lo hace de forma totalmete distinta, primero, trabaja con un modulo de datos donde tiene el SQLConnection y todas las SQLTables y SQLQuerys, se conecta una sola vez al inicio del programa y se desconecta al final de la aplicacion, en los formularios tiene componentes de datos como DBGrids, DBedit, etc. donde carga los datos de las tablas durante toda la ejecucion del programa... en fin. Mi pregunta es ¿Cual es la forma adecuada de trabajar las conecciones para liberar de trabajo al servidor y hacer mas eficiente la aplicacion?. Gracias de antemano por cualquier aporte.

[[__hector]]

Cada conexion/desconexion implica tiempo, por lo que la aplicacion, aunque sea en expresion de milisegundos, debera ir mas lenta. Con relacion a una conexion permanente, el unico problema que puedes tener es si tienes restricciones de licencias (por ejemplo), ya que una conexion inactiva (pero abierta) no debe consumir recursos del servidor.

De hecho, en SQL Server existe un concepto de 'pooled connections' o un pool de conexiones, que funciona mas o menos de la siguiente forma: un usuario realiza una conexion a la base de datos, y al dejar de usarla la conexion queda 'viva' (pooled) en el servidor, de forma tal que si otro cliente (con el mismo usuario,por supuesto) requiere servicios de la base de datos, sql server se ahorra el tiempo de crear/abrir la conexion, reutilizando una de las que ya estan en la cola.

[mamcx]

En base a lo dicho por hector quiere decir que se debe usar el mismo connection string sin la mas minima diferencia y en el caso de autenticacion windows sobre el mismo usuario.

Un sistema que abre la conexion hasta el ultimo momento y la cierra tan pronto puede tiene mayor escalabilidad y promueve un diseño "sin estado", pero si sera mejor desempeño, mas o menos,el tener una sola conexion en un ambiente de escritorio (en un ambiente de servidor es mejor usar la opcion de conectar/trabajar/desconectar).

Ahora bien, por la experiencia me parece que en ambiente de escritorio deberia haber al menos 2 conexiones: Una para edicion y otra para consultas/informes. La conexion de consultas se configura con el correcto aislamiento de transacciones y para mayor velocidad de lectura.

De todas maneras, me parece que es mejor ir directo al diseño de conectar/trabajo/desconectar, no tanto por la ganacia o perdida de desempeño, sino porque el codigo es mas claro y se evitan los efectos colaterales. Pero de ninguna manera eso exige perder la facilidad que da el pensar que solo hay una sola conexion activa.

Si te fijas en mi blog (http://www.solucionesvulcano.com/blo...mejor-rad.html) existe una idea de como hacer una clase que solo requiere un unico punto de cambio en este aspecto, y que ademas el dia que necesites portar a un ambiente de servidor no vas a sacrificar nada.

[pkbza]

Gracias por sus opiniones, veo que hay ventajas en ambos casos, debo aclarar que trabajamos con un servidor de BD y aplicaciones en estaciones de trabajo que se conectan al servidor, ahora me surgen otras dudas, que hay con la red, ¿Hay mayor trafico realizando varias conecciones/desconecciones o dejando una abierta todo el tiempo por usuario?.
Mamcx, ¿A que te refieres con diseño "sin estado" y a una mayor escalabilidad ?.

[mamcx]

Deberia existir menos trafico conectando/desconectando, pero la razon es que se debe acompañar de un buen uso de estrategias de cacheo, por ejemplo, descargar la lista de ciudades en un ClientDataSet y dejarla alli en el cliente, y no reconsultarla cada vez.

Para programar en red haz de cuenta que se trabaja en batch: Ejecutas una funcion que manda en un solo paso todo lo que mas se pueda y que retorne en un solo paso lo mas que se pueda.

Por ejemplo, si tienes un codigo como:

Abrir Lista Clientes. Ir al primero. Leer campo Id. Leer campo Nombre. Leer Campo Fecha.

Si estas conectado directamente al servidor el trafico va a aumentar. La razon: http://www.solucionesvulcano.com/blo...-primeros.html

Lo que se debe hacer es:

Traigame todos los datos del cliente, filtrador por, en esta estructura de memoria. Punto.

Lo de "sin estado" quiere decir que el servidor esta hecho de forma "olvidadiza": Si te vi, no te conoci...

Una comunicacion con estado es como hablar por telefono. Marcas, te contestan y empiezas a hablar. En todo momento tu sabes con quien hablas y al otro lado saben que hablan contigo. En todo momento, las partes tienen que recordan que estan hablando de tal tema y que estan hablando con tal persona.

Ahora imaginate que 4 personas quieren hablar entre si. Y luego 10. Pum!!! un problema de escalabilidad.... es muy dificil recordar que estaba hablando con mi abuelita de ir al medico y con mi medico de ir a ver futbol. Luego le digo a mi abuelita que nos vemos a las 5 y al medico que vamos a las 10. A las 5 era el partido de futbol!

Sin estado es como enviar email. "Hola compadre, vamos a futbol" te responde "Claro, pero tengo que chequear aquello" "Mijo, cuando me lleva al medico?" "Listo cuate, nos vemos a las 5" "Ok abuelita, que tal a las 10?"

Es obvio que es mas facil responder MUCHOS correos que hablar con MUCHAS personas. Los correos no estan conectados de forma dirtecta, sino que contienen los datos que permiten recordar de que se estaba hablando (el famoso re: Conversacion inutil, de: medico@futbolista.com para:yo@casa.net)

La arquitectura de red esta hecha de forma similar a un sistema de correo, es por eso que un servidor web es escalable, una vez que termina una tarea, se olvida completamente de quien se la pidio y solo vuelve al tema si se le informa los campos de, para, y de que estaban hablando.

En terminos practicos quiere decir que:

Clientes.Active:=true;
Clientes.First;
Clientes.Insert;
Clientes.Post;
Clientes.Close;

Es una "llamada telefonica". No hay forma de hacer Clientes.First si no se tiene la direccion de memoria de clientes y se sabe que ANTES se hizo Clientes.Open.

En un "sistema de correo" se haria.

IdCliente := AgregarCliente(DatosCliente):Integer;

Ahora tenemos un campo "para". Con esto podemos:

ActualizarCliente(IdCliente,NuevoNombre);

Pero en el servidor no se sabe que antes le dimos agregar cliente. Lo unico que sabe es que le llega un correo pidiendo que haga algo, lo hace y responde.

Para hacer un sistema de correo escalble, se programa en batch. Se mandan con parametros las instrucciones de lo que hay que hacer. Se abren solo los recursos necesarios (como conexiones de BD), se ejecutan las tareas y se cierran los recursos. Se retornar el resultado de la conversacion (cuando sea necesario).

[pkbza]

Bueno, por lo que rescato del tema, estoy en buen camino desarrollando de esa forma mis aplicaciones, pensando en entorno de un servidor de BD y multiples clientes solicitando datos. Ahora, siendo tecnicamente detallista y abusando de vuestro conocimiento, ¿Los SQLConnection y SQLQuerys son los componentes adecuados?, ¿Su ubicacion adecuada son los modulos de datos o da lo mismo?.

[mamcx]

Da lo mismo la ubicacion. Los componentes estan bien. Es mas bien el uso que les des. Deberias investigar mas acerca de las estrategias de desarrollo de aplicaciones cliente/servidor para que te des una mejor idea...

[pkbza]

Muchas gracias Mamcx por tu tiempo, es una buena orientacion, investigare un poco mas para hacer un buen trabajo, gracias nuevamente, saludos.