Eric
2008/10/1, Eric Z. <[EMAIL PROTECTED]>: > > Ricardo: > > Yo arme un sistema que si bien laburaba localmente necesitaba > de la central conectarse para consultar datos (stock y demás) y arme un > componente en FOX corriendo en el SERVER que se conectaba a través de una > VPN y consultaba. El componente consultaba una BD en postgreSQL. Es una > forma de trabajar. > > Pero es mucho mas fácil por escritorio remoto obvio mientras tengas > Internet ya que se cae el servicio y no hay sistema. Y si el sistema es de > Critico esta en un problema. > > > > Saludos, Eric! > > > > Eric G. Zbrun > > Ingeniero en Sistemas Informáticos > > Dpto. Desarrollo > > Sistemas C&P > > www.sistemascyp.com.ar > ------------------------------ > > *De:* [email protected] [mailto:[EMAIL PROTECTED] *En nombre de *Pablo Pioli > *Enviado el:* Martes, 30 de Septiembre de 2008 22:45 > *Para:* GUFA List Member > *Asunto:* [GUFA] Escritorio Remoto vs Motor BBDD Cliente Servidor > > > > En realidad para acceso via Internet yo usaria escritorio remoto. > > > > Acceder a la DB via internet es exponerla a cualquiera arriesgandote a > problemas de seguridad. > > Por otro lado, dependiendo de la conexion que tenga el servidor > (especialmente el upload) es posible que los usuarios se quejen por la > velocidad de acceso a los datos. > > > > Una base de datos cliente-servidor tiene muchas ventajas pero no creo que > cambiar a este esquema se justifique solo por acceder a los datos via > internet. > > > > Pablo Pioli > > ----- Original Message ----- > > *From:* Ricardo Pina <[EMAIL PROTECTED]> > > *To:* GUFA List Member <[email protected]> > > *Sent:* Tuesday, September 30, 2008 10:08 PM > > *Subject:* [GUFA] Escritorio Remoto vs Motor BBDD Cliente Servidor > > > > Parece que es asi nomas > > Tengo claro las ventajas de trabajar con una arquitectura cliente/servidor > y estuve investigando sobre las prestaciones de Postgresql para evitar el > uso de licencias y en la mayoria de los casos recibi muy buenas referencias. > > Mi consulta era porque tenia que defender ante el cliente la migración, ya > que tiene sus necesidades satisfechas con la implementación del escritorio > Remoto y queria "venderle" el cambio de arquitectura detallandole que > ventajas iba a recibir con esto. > > Bueno, espero poder serte útil a la brevedad > > > > Saludos > > Ricardo Pina > > > > > > > > > > El 30 de septiembre de 2008 19:20, Eric Z. <[EMAIL PROTECTED]> > escribió: > > Parece Ricardo que te puedo seguir ayudando.. ja! > > Yo te recomiendo PostgreSQL realmente me ha sorprendido por ser un producto > Open Source y además muy completoa diferencia del Mysql. Es un tema la > configuración de la seguridad pero es muy bueno y muy estable. Ahora si tu > base no va ocupar mucho podes darle con SQL 2005 Express que hasta 2 o 4 Gb > va. El tema que si hay alguna PC cliente con Windows 98 olvídalo. No hay > forma de conectarla. > > Link http://www.postgresql.org/ > > La justificación de migrar es que veas las ventajas de arquitectura Cliente > / Servidor, Seguridad de Base de Datos, etc. (link como para empezar > http://es.wikipedia.org/wiki/Servidor_de_base_de_datos ) > > > > Saludos, Eric! > > > > Eric G. Zbrun > > Ingeniero en Sistemas Informáticos > > Dpto. Desarrollo > > Sistemas C&P > > www.sistemascyp.com.ar > ------------------------------ > > *De:* [email protected] [mailto:[EMAIL PROTECTED] *En nombre de *Ricardo Pina > *Enviado el:* Martes, 30 de Septiembre de 2008 10:34 > *Para:* GUFA List Member > *Asunto:* [GUFA] Escritorio Remoto vs Motor BBDD Cliente Servidor > > > > Sres/as gufas > > > > Qué opinan? Tengo desarrollado un Sistema en VFP7 que trabaja con bases > nativas fox, por requerimientos de un cliente debe entrar desde dos puntos > distantes (CapFed y Mendoza). Lo solucioné con la implementación de un > escritorio remoto pero se me planteó la posibilidad de migrar a un motor > Cliente Servidor (Postgres - MySql). Qué ventajas y desventajas ven de > trabajar con motor Cliente Servidor con respecto al ER del que hablé que > justifiquen o no la migración? > > > > Gracias > > Ricardo Pina > > > > > >
