Sugerencias para software de captura masiva de datos

[ivantech]

odbc, bueno es que estoy utilizando algo totalmente orientado al sistema operativo y que no halla demasiado complejidad para instalar. hasta ahora no he utilizado otra herramienta si tienen alguna en mente pues estoy abierto a sugerencias.

[ivantech]

el tema no es de capacidad, ya comprobé en otras consultas que firebird lo manejaría sin ningún problema, sino la mejor forma de hacer un sistema que va a capturar datos masivos sin ningún proceso de validación, es decir, este sistema no tendrá que conectarse a otra base de datos y validar el numero de Cédula para ver si esa persona es quien dice ser, ya que en salud a ti o cualquiera te van a atender como quiera, ademas casi el 90% de los campos a capturar están en lista de combobox eso reduciría la posibilidad de escribir. ademas el formulario es llenado por un personal de salud y el digitador solo registraría lo que dice el formulario. estamos de acuerdo que no es la mejor forma, pero es lo que hay en este momento, luego vendrán otros modelos posiblemente basados en webservices que garantizarían lo que ustedes exponen. pero ese no es el caso en este momento.

[mamcx]

Hacer las cosas "bien" NO es enemigo de hacerlo "rapido".

Al contrario, es su mejor amigo. Todo lo que aparentemente te ahorras al inicio lo pierdes con creces despues.

Ademas, si solo hay un paso de datos de aqui a alla sin nada complejo, la cosa es superfacil. Se peude tener un prototipo funcional de eso en pocas horas donde se almancene de forma local y luego se envian a un servidor central los datos usando remobjects (lo que mas me gusta) o usando la nueva funcionalidad de datasnap de delphi 2010.

Incluso se puede hacer "a pelo" con Indy o Synapse en poco tiempo.

pero debes entender que si el sitio donde se va implementar actualmente no existe ningún tipo de herramienta implementada y no existe cultura no importa que lleves el supersistema on line o multi capas como lo quieras llamar va a fracasar.

Eso describe a la casi totalidad de todos los usuarios/empresas. Es por eso que estan dependiendo en TU trabajo (conscientes de ello o no).

La totalidad de mis clientes actuales (de http://www.bestsellerapp.com) es como dices. Es una aplicacion en el iPhone para toma de pedidos. Los usuarios principales tiene poco o ningun conocimiento de sistemas. Algunos son casi analfabetas (no es broma). Algunos operan a pocos kilometros de la selva del chocó y de la selva de uraba, sin electricidad ni internet. El "servidor" es supercutre en la mayoria (= el equipo de la secretaria). Y sin embargo, la aplicación es muy solida. No requiere nada sofisticado (para el cliente). Y nunca jamas les explico la arquitectura (ni me la han preguntado). Lo que ellos ven es que le dan play, le dicen el ERP que tienen instalado y es todo.

No depende de la preexistencia de nada en el sistema. No depende de drivers. No necesita ni apache ni internet information server. La BD esta embeida y no se necesita ni mantener ni configurar ni nada. Llegue hasta el extremo de que el usuario no necesita saber la IP o direccion del servidor (el servidor le informa a los clientes donde esta! - una funcionalidad de remobjects-).

Le he trabajado mucho a todo eso. Y porque? Porque no hacer la "facil" como todos? PRECISAMENTE porque las circunstancias de mis clientes son "toxicas" en cuanto a tecnologia. Hay uno que le da rabia de la mala los computadores (y madrea sobre el tema que da miedo!).

Pero esa es la tarea de un ingeniero. Es hacer soluciones robustas. Hacerlas resistentes. Hacerlas bien. Y si el cliente pide lo contrario, es responsabilidad de uno IGNORARLO. Porque este solo tiene la razon en cuanto a lo que quiere. Pero no en cuanto a como debes TU hacer el trabajo. Eso es cosa 100% tuya.

[Casimiro Noteví]

Estoy de acuerdo con lo que comenta mamcx y AzidRain. Es una oportunidad para hacer un buen trabajo que beneficiará al conjunto de la población del país y hacer ese sistema de la forma en que está pensada es simplemente una pérdida de tiempo y de dinero que no sirve para nada.

[ivantech]

de acuerdo,

entonces vamos a recomponer de nuevo todo, favor de explicarme como lo comienzo, es decir, los siguientes factores que vamos a tener son:

los centros de digitacion y acopio no tienen acceso a internet, y en esta etapa no esta previsto invertir en internet eso me lo dejaron muy claro. entonces como lo haríamos, porfavor orientenme ya que no he tenido mucha experiencia con aplicativos mas alla de una red LAN. y tengo por política no recomendar lo que no puedo manejar.

que conste, nunca he esta en desacuerdo con ustedes, pero como no tenia mucho de donde elejir eso fue lo que se me ocurrió, transferir los datos a través de archivos TXT enviándolos por cualquier medio y en la oficina central una aplicación que leyera dicho archivo e importara el dato y rechazara el que no cumpla con ciertos criterios.

OJO: tampoco quiero que se entienda que tienen que hacer dicho proyecto, ya que estoy consciente de que solo me pueden hacer sugerencias desde sus puntos de vista, pero es que nunca había trabajado proyectos que se conectaran a replicacion y no tengo idea por donde comenzar.

les estoy muy agradecido a todos por sus comentarios, muchas gracias

[Neftali [Germán.Estévez]]

Antes de nada, he de decir que mi primera impresión ha sido similar a la de otros compañeros. Me daba la impresión de que el proyecto se estaba enfocando mal, en el sentido que que se estaban dando muchas vueltas para hacer algo que se podía hacer de forma sencilla y mejor.

También es verdad que muchas veces damos por supuestas cosas que no lo son, como que todo el mundo tiene acceso a un equipo medio-alto, conexión a internet, velocidad tipo "ADSL",...

Tal vez la suposición a sido incorrecta, y se hubiera evitado si de primeras hubieras comentado esa cuestión "levemente" importante de acceso a internet... ;-)

Empezado por ivantech

PREMISA: Los centros de digitacion y acopio no tienen acceso a internet, y en esta etapa no esta previsto invertir en internet eso me lo dejaron muy claro.

OK.
A partir de esta premisa ¿Qué nos queda?

(1) Si hay línea telefónica.
Lo único que se me ocurre en este caso es utilizar módems. Tendrían que estar dispuestos a comprarlos (creo que son bastante asequibles de precio) y en este caso buscar cómo implementar una comunicación vía modem.
Al final el sistema sería parecido al que comentas, pero el envío se haría vía modem-modem.
Las ventajas en este caso serían la fiabilidad y la rapidez. Las desventajas, que el sistema se complica (por el tema de la comunicación), se encarece y es más propenso a errores "técnicos".

NOTA: Si esta opción es viable, dilo y podemos ahondar en este camino...

(2) Si no hay línea telefónica.
Pues no hay mucha más opción que la que comentas. Generar un fichero TXT/CSV/DBF (como más te guste) que envías a la central y que allí importan.

La única "pega" que le veo al sistema que comentas: delphi 7 + ADO + ODBC + Firebird 2.1 es la forma de acceder a FB. Hacerlo vía ADO+ODBC no es la forma más directa y seguro que hay componentes de acceso nativo a FB para poder hacer: delphi 7 + CompNativo + Firebird 2.1 y ahorrate así un paso.

[Casimiro Noteví]

Para poder opinar con más seguridad necesitamos conocer más a fondo el proyecto.
Suponemos que se van a recoger unos datos mediante un formulario, ¿están asociados esos datos a códigos de pacientes?, ¿esos códigos son independientes para cada uno o se repiten en cada centro de salud?, ¿con qué propósito se recogen esos datos?, ¿para qué se quieren centralizar?, etc.
En fin, conocer más del proyecto y su objetivo.

[[AzidRain]]

Andale Casimiro, coincido, con esos datos si podemos pensar en alguna solución. Ya nos quedó claro las limitantes del caso obviamente hay que pensar en todos los puntos que hay que cuidar y por donde la cosa puede fallar. Un punto que considero muy importante es asegurar la calidad de los datos capturados ya que no hay contra qué validarlos al momento de hacer las capturas. Hay que pensar en una manera de asegurarnos que el "paquete" con la información capturada es correcto.