Base de Datos remota

Por favor explique qué tipo de arquitectura y aplicaciones usan los usuarios
para acceder a SQL Server.

Son aplicaciones web? Aplicaciones gruesas cliente/servidor en 2 capas? Otra
cosa?

Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gux
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"Cristian Meneses" wrote:

Buenas a todos
Tengo una consulta, y es que quiero instalar SQL Server 2000 SP4 en
una sucursal de un cliente que esta a varios kilometros como para
hacer una LAN. Como tienen internet por adsl, se me ocurre poner un
servicio de dyndns por ej: empresacliente.dyndns.org y luego llamar a
la conexion por este nombre + autenticacion sql.
Es correcto lo que quiero hacer? Hay que instalar algo mas para que
SQL 2000 soporte este tipo de conexiones? Que sugieren los expertos
del tema?
Saludos


Cristian Meneses

Hola Gustavo
Es una aplicacion cliente/servidor realizada en visual basic 6. El
servidor y los clientes estarian instalados en un ordenador con xp
sp2.
Los usuarios usan para conectarse autenticacion por sql y ADO.
Saludos


Cristian

Para una aplicación de ese tipo, el éxito dependerá del ancho de banda y
velocidad de la red. No es una arquitectura amigable para hacerlo por
internet, donde los problemas de red son frecuentes.

Mi recomendación, a muy alto nivel, es que evalúe a poner las aplicaciones
cliente en un servidor del lado de SQL Server y acceder por Terminal Services
(la componente cliente de TS para browser tiene una usabilidad más que
aceptable).

Por supuesto que creo que la situación ideal sería que la aplicación se
hiciera de tipo web, pero entiendo que es como hacerla de nuevo.

Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gux
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"Cristian Meneses" wrote:

Hola Gustavo
Es una aplicacion cliente/servidor realizada en visual basic 6. El
servidor y los clientes estarian instalados en un ordenador con xp
sp2.
Los usuarios usan para conectarse autenticacion por sql y ADO.
Saludos


Cristian

Hola Gux,

On Fri, 14 Dec 2007 06:46:01 -0800, Gux (MVP)
wrote:

Para una aplicación de ese tipo, el éxito dependerá del ancho de banda y
velocidad de la red. No es una arquitectura amigable para hacerlo por
internet, donde los problemas de red son frecuentes.

Creo que depende más de lo eficiente que sea SQL Server con el uso de
la red y de lo bien o mal hecha que esté la aplicación.

Mi recomendación, a muy alto nivel, es que evalúe a poner las aplicaciones
cliente en un servidor del lado de SQL Server y acceder por Terminal Services
(la componente cliente de TS para browser tiene una usabilidad más que
aceptable).

Es una solución muy cutre pero si la aplicación no está muy bien hecha
muchas veces es la menos mala.

Por supuesto que creo que la situación ideal sería que la aplicación se
hiciera de tipo web, pero entiendo que es como hacerla de nuevo.

¿Ideal? :-O

Pero si las aplicaciones Web tienen una "usabilidad" muchísimo más
pobre que los clientes Widows, y además tampoco hacen muy buen uso del
ancho de banda.

La productividad del trabajo con aplicaciones Web es bajísima.

Normalmente no te importa que un cliente tarde 5 veces más en
comprarte algo, por que el tiempo que se pierde es el suyo y no el
tuyo. Pero si es una aplicación de uso interno, entonces no es muy
interesante perder el 80% de la productividad por usar una aplicación
Web.

Yo creo que sería mucho mejor poner un servidor intermedio que
optimice el uso de la red, en caso de que no vaya muy bien conectando
directamente a SQL Server a través de Internet.


Saludos
Alfredo

Hola Alfredo,

"Alfredo Novoa" wrote:

On Fri, 14 Dec 2007 06:46:01 -0800, Gux (MVP)
wrote:

>Para una aplicación de ese tipo, el éxito dependerá del ancho de banda y
>velocidad de la red. No es una arquitectura amigable para hacerlo por
>internet, donde los problemas de red son frecuentes.

Creo que depende más de lo eficiente que sea SQL Server con el uso de
la red y de lo bien o mal hecha que esté la aplicación.

La mayoria de las aplicaciones cliente/servidor que se hacen suelen asumir
que hay conectividad constante con el servidor de base de datos y no toman
mucho recaudo acerca de cómo trabajar en redes de baja calidad (como lo es
Internet en la gran mayoría de los casos).

Por supuesto que desconozco la aplicación del amigo y no quiero decir que su
aplicación funciona como acabo de mencionar.

>Mi recomendación, a muy alto nivel, es que evalúe a poner las aplicaciones
>cliente en un servidor del lado de SQL Server y acceder por Terminal Services
>(la componente cliente de TS para browser tiene una usabilidad más que
>aceptable).

Es una solución muy cutre pero si la aplicación no está muy bien hecha
muchas veces es la menos mala.

Una aplicación cliente/servidor, no bien diseñada para trabajar en forma
desconectada o con desconexiones ocasionales, muchas veces se puede mover de
una LAN hacia Internet con artilugios como las terminales remotas.

>Por supuesto que creo que la situación ideal sería que la aplicación se
>hiciera de tipo web, pero entiendo que es como hacerla de nuevo.

¿Ideal? :-O

Sí, ideal.

Si la infraestructura de red disponible solamente es Internet, la aplicación
tiene que ser diseñada para comportarse dignamente en Internet. Y una
aplicación cliente/servidor con cliente grueso, no va a funcionar
decentemente en Internet a menos que se tenga un enlace similar al de una LAN.

Pero si las aplicaciones Web tienen una "usabilidad" muchísimo más
pobre que los clientes Widows, y además tampoco hacen muy buen uso del
ancho de banda.

Estoy de acuerdo con que la usabilidad del browser es más pobre. Pero tiene
otras ventajas: No requiere instalaciones cliente y solamente requiere un
browser decente corriendo en cualquier plataforma de sistema operativo.

De todas formas hoy en día la usabilidad de una aplicación web ha mejorado
muchísimo con las sucesivas modas (DHTML, Activex, applets Java, Flash, .NET
Webforms, AJAX, ... y las que se sigan inventando para que una aplicación web
se parezca bastante a una aplicación de escritorio).

La productividad del trabajo con aplicaciones Web es bajísima.

No hay duda de ello. Pero depende de dónde el arquitecto rankee
productividad frente a otras cualidades de la aplicación.

Yo creo que sería mucho mejor poner un servidor intermedio que
optimice el uso de la red, en caso de que no vaya muy bien conectando
directamente a SQL Server a través de Internet.

Por favor puede usted extender más su idea? No percibo con claridad cómo
pasar una aplicación cliente/servidor a usar un servidor intermedio (que
optimice el uso de red? cómo? qué es exactamente lo que hace este servidor
intermedio?).

Si fuera una aplicación web me resultaría evidente poner un servidor
intermedio (el servidor web, por ejemplo), pero no para el caso que ha
planteado el amigo.

Saludos
Alfredo

Saludos
~gux