Creo que había un hilo donde se hablaba precisamente de esto.
En primer lugar, ni que decir tiene que las conexiones tendrán que ser adsl en todos lados, aunque sea la normal de 256 kb y en la central si es adsl de 2 mb mucho mejor.
Yo he hecho conexiones así, utilizando Zebedee. Éste es un programita que comprime los datos y los envia entre las máquinas por el puerto que tu elijas. La ganancia en velocidad no es mucha, pero como tambien encripta los datos y el programita es gratuito...
¿Que si es lento? Hommmmmbreeeeee......., pues, que quieres que te diga, muy rápido rápido no es, sobre todo cuando estás acostumbrado a trabajar en la red local, donde firebird va cono un rayo endemoniado; te acostumbras a las consultas cuasi-instantáneas y luego si tardan 1,3 segundos te parece que tardan mucho.
Pero tambien te digo: es manejable si te lo curras. Quiero decir que depende de como sea el programa lo trabajas y puedes llegar a conseguir resultados más que aceptables.
Me explico: en primer lugar tienes que seguir las reglas básicas de cualquier programa cliente servidor, me refiero a que las búsquedas hay que acotarlas muy bien, obligando al usuario a que especifique concretamente qué es lo que quiere buscar y luego devolverle un conjunto de registros reducido de acuerdo con lo que quiere. Nada de dbgrid's con 15.000 registros.
En segundo lugar, te comento lo que yo hago, aparte de lo anterior. Utilizo componentes FIBPlus pero creo que con los mismo IBX se pueden conseguir los mismos resultados. Hay transacciones de lectura y escritura separadas (por lo menos una de cada lógicamente). Las de lectura tienen el parámetro read de manera que no pueden escribir ni por un fallo tuyo o de tu programa. Éstas las usan componentes dataset que están conectados a grids de búsquedas, que, como dije antes, devuelven resultados que el usuario ha especificado y delimitado muy bien previamente. Ese conjunto de datos luego se queda en local y el usuario puede ordenar por el campo que quiera y hacer agrupamientos en el grid SIN tener que volver a mandar o recibir nada desde el servidor hasta que se haga una nueva consulta. En estos grids sólo se muestran algunos campos significativos, aquellos que el usuario utiliza para buscar y diferenciar claramente un registro de otro, y está claro que sólo son de lectura. Los dataset están basados en vistas de la base de datos, aunque por aqui se ha dicho que si estuvieran basados en procedimientos almacenados sería mayor su rendimiento: yo no lo hago así porque el rendimiento de la vista me parece bueno, ya que en este caso de lo que depende la cuestión no es rendimiento del servidor al hacer las consultas sino del tráfico de la red
Sigo: cuando el usuario hace doble click sobre una fila del grid se abre otro formulario con una vista completa de todos los campos de ese registro. El usuario puede entonces modificar el registro o eliminarlo si tiene permiso para eso. Hay un botón para añadir nuevos registros que abre otro formulario heredado del anterior que sirve para eso. Todas estas operaciones de inserción, modificación y borrado los hago con un componente llamado fibquery, que se comporta igual que el ibsql de las ibx. Incluso para leer el registro completo antes de mostrarlo utilizo dicho componente; para rellenar los combobox también utilizo este componente. No hay controles enlazados a datos de ningún tipo sólo los grids de lectura comentados anteriormente. Todos los formularios se basan en controles normales, los cuales "relleno" con una consulta mediante fibquery (o ibsql o similares) y cierro la transacción. Después el usuario rellena los campos o hace las modificaciones pertinentes y compruebo los datos, construto la instrucción sql, abro transacción, envio instrucción (insert, update, delete) y cierro la transacción. Digo que compruebo los datos en el programa antes de enviar la instrucción y si alguno no cumple las normas se lo hago saber al usuario y cuando esté todo correcto es cuando envío la instrucción. La comprobación de los datos está incluida dentro de la base de datos pero yo también los compruebo antes de enviarlos, es mejor así que enviar datos inválidos por la red y mandar un evento de vuelta.
Luego, los fibplus pueden, en los datasets, actualizar sólo los registros modificados, no se si tambien lo hacen las ibx, y eso es lo que hago.
Quien hay leido esto puede pensar '¡Vaya ganas de complicarse la vida!' y tiene razón. Se que más o menos esto se puede conseguir con menos trabajo. Los mismos fibplus tienen métodos para conseguir esto mismo, pero el caso es que quería hacerlo yo de esta manera. Me gusta controlar en cada momento lo que está pasando, abrir y cerrar yo explícitamente cada transacción, mandar cada instrucción sql. ¡Lo confieso, en tozudez no hay quien me gane!.
Ahora bien, los programas funcionan a las mil maravillas en red local. Y en internet ya digo, van aceptablemente bien, se puede trabajar.
Para terminar quiero decir que hay otras opciones, como trabajar con datasnap y trabajar en local y luego de vez en cuando conectar con el servidor remoto, mandar las modificaciones y recoger nuevos datos, al estilo cajero de banco. Así tambien podría ir bastante bien, pero sobre esta opción te podrán hablar mejor otros compaleros del foro.