Ver Mensaje Individual
  #6 (permalink)  
Antiguo 04/10/2011, 03:07
moeb
 
Fecha de Ingreso: febrero-2011
Mensajes: 581
Antigüedad: 13 años, 2 meses
Puntos: 81
Respuesta: servidor base de datos conectar ciudades

Umm... Desde luego no pretendo EN ABSOLUTO mostrar una diferencia de opiniones... Pero este tema debería ser "matizado", para que nadie se lleve a error. Esto va a ser largo... sorry :)

Veamos... Umm... El acceso a BBDD se puede realizar de multiples formas. El acceso a un motor de BBDD avanzado vía red, tan sólo implica tráfico de texto en el protocolo...

Es decir, si accedes a un Oracle, SQL-Server, MySQL, DB2, Postgres, etc, LAS PETICIONES no ocupan un gran ancho de banda. Eso implica que el trabajo gordo se realiza en servidor... Las "vistas" se generan en servidor, los resultados intermedios de "sorts" se realizan en servidor, y tan sólo se te envía la respuesta a tu consulta una vez finalizada... ¡OJO!... NO CONFUNDIR CON BASES DE DATOS TIPO ACCESS (o dbf, .db, etc)... Tablas basadas en ficheros y no en motores de BBDD ABREN TODO el fichero, con lo que el trabajo via red es inviable (y no se conectan a l aBBDD a través de un puerto, sino que utilizan acceso a archivos normal... Generalmente via SMB).

En otras palabras... Si pretendeis atacar un Access a través de una VPN... Estais jodidos. Terminal server es la única opción. Si, por el contrario, como se asumía en este hilo, dicha BBDD es un motor en toda regla, atacar DIRECTAMENTE EL PUERTO de BBDD a través de una VPN es perfectamente viable (repito, siemrpe en mi experiencia).

El UNICO problema, trabajando en remoto, que podrías tener con este tema es que utilices un estilo de programación y un lenguaje que trate de realizar sorts en local para utilizar determinados objetos de visualización de BBDD (como algunos tipos de grid)... En ese caso, es posible que aunque tú tan sólo requieras 5 tuplas para tu cliente, dicho lenguaje se traiga toda la tabla y te muestre sólo las 5 que necesitas (pero habrás movido toda la tabla entera). Esto suele ocurrir con objetos Dataset de tipo "table" en lugar de tipo "query" (es decir, objetos en los que no escribes explícitamente la consulta SQL... Son objetos tremendamente ineficientes, de los que se debe huir siempre que se pueda y cuyas ventajas son ampliamente sobrepasadas por sus desventajas... Objetos tipo "query" son mucho más eficientes y recomendables).

Tambien depende de la forma en que hayas programado tu aplicación... Lógicamente, si pides un registro el tráfico será escaso. Si pides 1.000.000, el tráfico será bastante mayor...

Aún así, y EN MI EXPERIENCIA, atacar una BBDD de este tipo a través de una VPN es perfectamente viable. La mayor parte del trabajo debería realizarla el motor de BBDD y debería devolverte un subconjunto de datos perfectamente manejable.

Como os digo, nunca he tenido problemas atacando una BBDD en remoto tipo Oracle, MySQL, Postgres o DB2... Y hablo de "atacar" en el contexto de establecer conexiones cliente/servidor.

Si no tienes demasiados usuarios, o si dispones de unas máquinas muy potentes, Terminal Server es otra buena opción....

En definitiva, en este caso concreto, no estoy de acuerdo con BrujoNIC en que

Cita:
los tiempos de respuesta van a ser muy lento y más aún si al realizar cualquier consulta de BD y este genere vistas para mostrar el resultado"
El tiempo de respuesta será más lento que en local (cosa que se asume dado que se DEBE trabajar en remoto)... Pero ni mucho menos algo insufrible. Como digo, depende bastante de como programes tu aplicación... Y del tipo de vistas que generes (deberías generarlas en servidor y enviar solo la parte que requieras).

He programado, e instalado multitud de aplicativos en remoto, propios y de terceros, desde aplicaciones de control y gestión de obra, a cadenas de tiendas... Y nunca ha sido traumático, ni mucho menos, el trabajar en remoto (de hecho, muchísimas cadenas de tiendas funcionan así).

Obviamente, cuanto mejor caudal de subida tengas en la central mejor...

Vamos, que dependerás mucho de como esté programada la aplicación. La respuesta es simple:

Monta la VPN (esto es impepinable para mi) y realiza pruebas... Si tu aplicación va bien en entorno cliente servidor desde remoto... Genial. ¿Que no? Prueba por terminal server (pero necesitarás una máquina servidor de terminales bastante potente, en función de tu numero de usuarios concurrentes).