Sugerencias para software de captura masiva de datos

[[gatosoft]]

Me uno al comentario de Casimiro, sería bueno que nos cantoras mas detalles... por ejmplo:


1) ¿Puedes definir / decidir el formato en el que llega la información?
2) ¿Tienes límites de tiempo para recibir / Cargar información ?
3) ¿El proceso entero se debe hacer en u punto central?, ¿Has pensado en instalar software de apoyo en puntos satelite, para ayudar al cargue? (Solo especulo)
4) ¿Como visualizas la recolección d ela Info?, ¿llega por correo?, ¿Por FTP?
5) Hay un aplicativo que actualmente haga este trabjao?

En fin,,, son muchas cosas las que te podria preguntar... lo importante es tener claro que quieres, que quieren tus clientes, cual es el estado y la funcionalidad del sistema actual?, ¿Que cosas quieren mejorar del sistema actual?, ¿cuales son las Limitaciones o restricciones de lo que vas a implementar?...

En fin...

Un saludo,

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

Me uno a los dicho por los compañeros, y añado:

¿Desde dónde se van a realizar las inserciones?
¿Desde cuantos puestos? ¿Dónde va a estar el ejecutable (Local, Terminal Server, Ejecutable en Red)?
¿Intranet, Wan?

[[AzidRain]]

Nomas acoto, MySQL igual te sirve y es incorrecta tu afirmacion de que "está mas orientada a la web", lo que sucede es que PHP (que es el lenguaje para web mas difundido) incluye por default funciones para acceder aunque igual puedes usar FB para web.

Para entornos así con ese escenario MySQL tiene un pequeño detalle que a mi en lo personal me gusta bastante que es la replicación, FB no la trae integrada y hay que hacer algunas cosillas, con la replicación por ejemplo puedes destinar un servidor únicamente para recibir los datos y otro (el replicado) para dedicarse a atender las consultas, de esa manera divides bastante la carga. Otra ventaja es que MySQL te permite hacer clusters de servidores (no recuerdo si aún lo hace) lo que todavía potencia mas la distribución de carga entre varios equipos.

Otro punto muy importante es considerar la infraestructura, en proyectos así no solo participa el motor de BD, sino el servidor donde se monta, la infraestructura de red, la redundancia, etc. Son muchas cosas a tomar en cuenta pues si algo falla dejas sin servicio a miles de usuarios. Hay no muy gratas experiencias que me ha tocado arreglar en donde se echa a andar un proyecto que en un entorno mas o menos "normal" funcionaría sin problemas y la gente que lo implemente piensa que si funciona para 100 funciona para 100 mil y ya te imaginarás. Ojalá y des mas detalles para poder ayudarte mas concretamente.

[ivantech]

hola a todos,

pues vale y correcta sus observaciones, primero es que corroborando lo que casimiro dice, creo que había iniciado un tema sobre el mismo proyecto pero averiguando otros asuntitos que me fueron aclarados, y de antemano les agradezco pero el punto es que dicho proyecto esta casi comenzando y lo que quiero saber si existen técnicas para hacer interfaz de captura de datos de manera ágil y rápida ya que es mucha información y diaria. el software se esta elaborando en delphi 7 + Firebird 2.1 + ODBC + ADO, la herramienta después de capturada la información sera capaz de generar archivos TXT que se utilizarían para transmitir el dato al nivel superior que consolida la información.

el caso que se discute es buscar el mecanismo mas ágil para que el digitador le sea lo mas simple posible. el digitador recibiría en un centro de acopio correspondiente a su área varios formularios diarios para ser procesados, según el calculo seria:

en mi país existen 9 regiones de salud y cada región tiene 2 a 3 Gerencia de área de salud y a su vez c/u de las gerencias de area tiene bajo su control 5 a 6 Centros de Zona de Salud y a su vez cada Zona tiene 10 a 12 UNAP (Unidades de Atención Primaria de Salud, es decir, Clinicas Rurales en publitos y campos), estas UNAP tienen que ver en promedio de 25 a 30 Atenciones y/o Pacientes. entonces si hacemos el ejercicio seria:

30 atenciones * 5 días laborales = 150 atenciones semanales
150 atenciones * 12 UNAP = 1800 registros por ZONA DE SALUD a la Semana
1,800 * 6 ZONA DE SALUD = 10,800 registros por GERENCIA DE AREA a la Semana
10,800 * 2 GERENCIA DE AREA = 21,600 registros por REGIÓN DE SALUD a la Semana
21,600 * 9 REGIONES SALUD = 194,400 registros a Nivel Nacional (Rep. Dominicana) a la Semana
194,400 * 21 días laborales = 4,082,400 al Mes a Nivel Nacional
4,082,400 * 12 Meses = 48,988,800 al Año a Nivel Nacional

ese es el ejercicio que hemos realizado, y entendemos que es mucha información y para no crear cuellos de botella necesitamos una interfaz rápida y ágil y es por esto que apelo a sus experiencias para que me orientes con respecto a la mejor forma de hacer una herramienta local basada en Delphi 7+Firebird 2.1+ODBC y dicha aplicacion debe ser montada en no mas de 5 pasos (Motor BD, Conexion ODBC, Archivo INI, Carpeta donde esta BD, Carpeta donde esta Aplicación), ademas entran otros factores como son lo del soporte, esta aplicación debe ser lo mas simple posible para que no halla dificultades de soporte que detengan el proceso. por asunto de costes y complejidad no se contempla la herramienta ni en red, ni acceso a Internet, es decir, si se monta una red implicaría tener un personal técnico que resuelva los problemas que implica Internet, red y recursos compartidos, virus, puertos, permisos, etc. en esta etapa debe ser un proceso simple, cada equipo que digita entonces procede a vaciar los datos en un TXT y un personal pasaría semanalmente a recoger dichos archivos a cada centro, en Memorias, CD, DVD, etc. y llevarlos a la oficina Regional que es quien consolida su región. luego cada región remite un archivo a nivel regional al Ministerio de Salud que es el ente que consolidaría la información a nivel nacional.

con respecto a MySQL no quiero hacer desprecios sobre uno y otro Motor de BD, pero antes de seleccionar dicho motor (Firebird) realice una serie de consultas y ahí es que corroboro a Casimiro con su inquietud, ya que en las investigaciones anteriores una de las preguntas era sobre el motor de base de datos y obviamente salio ganadora Firebird.

espero haber sido un poco explicito y gracias por sus tiempos.

[Casimiro Noteví]

Si he entendido bien, en cada "puesto final" existirá un pc con el programa y su propia base de datos en firebird. En cada uno de esos puestos se exportarán los datos en diversos medios que acabarán todos siendo importados en un ordenador central que acumulará los datos de todos los demás.
Supongo que se habrá pensado en algún método para no repetir importaciones y llevar un control correcto.

De verdad, y puede que no quede muy bien decirlo, pero es lo que siento: mi sensación sobre ese sistema es que será un caos total y un descontrol absoluto.


p.d.: Por cierto, ODBD, ¿por qué?

[[AzidRain]]

Realmente es una lástima que se esté desarrollando un arquitectura tan pobre y tan deficiente para algo que es realmente importante para tu país. Ese esquema de los archivos de texto planos y de recopilar información y demás ya es por demás obsoleto y sujeto a múltiples errores y problemas adicionales que aunque parece que se "ahorra uno mucho" en realidad va salir mas caro de lo que piensan.

ODBC ya prácticamente es obsoleto además de que le mete una capa adiciona a tu sistema la cual no es necesaria para nada pues hay formas de accesar de forma nativa.

Ya lo dijo Casimiro, este sistema será un caos total pues lo que quieres hacer realmente se podría hacer prácticamente en tiempo real (o no Casimiro?) sin invertir millonadas en "soporte" y cosas así. Al final lo que se quiere es que la información sera fidedigna y lo más real posible puesto que de ahí se tomarán (supongo) decisiones...Pero bueno, creo que no es tu culpa y muy seguramente ya lo has pensado.

Se calculan 20 mil inserciones diarias, lo cual realmente es relativamente poco, lo que se debe calcular en todo caso es cuantas de estas inserciones pueden llegar a suceder en un mismo momento y dado que solo son pocos campos yo diría que es trivial ponerse a pensar en eso, cualquier motor te va a permitir manejar un buen número de inserciones en un instante determinado sin ningún problema, recuerda que se procesa conforme se va recibiendon y a no ser que tuvieras 20 mil inserciones en un segundo dado no veo como te pueda afectar meterlas en un servidor y aun en ese remoto caso, con solo aumentar las capacidades del servidor y algunos ajustes las podrás manejar sin problema.

[ivantech]

si estoy de acuerdo, pero que importa si es fidedigna, si al final el formulario es llenado por otra persona y no en tiempo real, es decir, no se va a realizar en el momento en que esta atendiendo a la persona. estoy de acuerdo que es pobre y deficiente, 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. esto es un experimente para probar a que nivel se puede capturar la información, ya después vendrán otras soluciones mas adecuadas. no se puede invertir mucho si no estas seguro de que puede funcionar correctamente. no es cuestion de pena, no lo veas asi, es cuestion de ensallo y error.