Sugerencias para software de captura masiva de datos

[ivantech]

saludos

no se si este es el apartado correcto, pero ahi les va.

actualmente estoy en planeacion de elaborar un software basado en un formulario que recoge información de atenciones en salud en a nivel nacional (Rep. Dominicana), el caso es que se va a capturar bastante información y no he tenido experiencia en estos tipos de software. el caso es que recurro a ustedes para ver si me pueden orientar para el diseño de este tipo de software, dicho software esta basado en un formulario con alrededor de 30 campos y se esta promediando que diario se va a capturar mas de 20,000 registros.

como motor de base de datos quiero proponer a Firebird 2.1 ya que MySQL es muy orientado a la web.

asi que porfavor les ruego que si existe alguna tecnica o mecanismo establecido para procesamiento masivo de datos favor orientarme ya sea con un documento o alguien que halla tenido alguna experiencia.

gracias de antemano.

[Casimiro Notevi]

Amigo, ivantech, creo que debes detallar más en profundidad todo lo que vas a necesitar para poder ayudarte.
En principio, te vale casi "cualquier" base de datos, por eso es que hace falta conocer los detalles.

p.d.: Por cierto, me ha venido a la mente alguien que preguntó algo parecido sobre el mismo tema, en tu mismo país.

[[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.