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.

[Casimiro Notevi]

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.

[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 Notevi]

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 Notevi]

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.

[ivantech]

hola

por donde comiezo, fijate

en dicha captura el 90% de los datos ya estan precodificados, solo un 10% de informacion se digita lo demas se selecciona de una lista. un ejemplo es que dicho formulario maneja el CIE10 y CIE9 que son códigos internaciones de clasificacion de procedimientos y diagnósticos de enfermedades. datos como la aseguradora y el regimen de salud al que pertenecen son seleccionables de una lista y ademas muchos datos son por default. la edad seria calculada en base a un algoritmo y la fecha de nacimiento. datos a capturar serian el nombre, fecha de nacimiento, dirección.

bueno adjunto les dejo una version prelimiar del formulario en formato de aplicacion. revisenlo y a ver que tal.

[ivantech]

con respecto a los códigos, se repiten en todas parte, es decir, es el mismo código en cada un a de las 9 regiones de salud que tiene mi país. el dato es redundante, es decir, cada vez que te atienden te vuelven a capturar el nombre y tus datos personales, por la misma naturaleza como no es un sistema on-line en la que construyes una base de datos de pacientes y/o usuarios entonces se redundaría en lo mismo, ya se realizaría un proceso de filtrado para unificar los datos. puesto que para el resultado de la información en esta etapa no nos interesa el dato de manera individual, sino que se sacan indicadores población mensual, bimensual, trimestral, semestral y anual, basándonos en los códigos de diagnósticos, procedimientos e intervenciones internacionales .

un ejemplo es, un informe que indique el los primeros 3 meses del año cuantos usuarios del servicio se enfermo de "dengue" en edades entre los 5 y 30 años del sexo femenino. es por ahí la cosa, pero no nos interesa saber quien se enfermo porque en las UNAP tienen el registro clínico del paciente y es al medico al que le interesa la información individual.

ya en lo adelante cuando se hagan las inversiones en conectividad podríamos analizar una estrategia para hacer una plataforma on-line que ayude a validar y crear bases de datos de usuarios del servicio y ademas ver información en tiempo real.

[[AzidRain]]

Entonces partimos de que cada registro no requiere ser identificado de manera única. Es decir no importa quien es el paciente sino sus datos.