HOla Alvaro, voy a ser mas explicito y explicarmen mejor:
Son datos de pacientes con sus respectivas historias de "x" enfermedad,
por ejemplo corazón, pues es:
La consulta al especialista, las pruebas que éste le manda, sus
resultados, examen fisico del médico (por eso de 90'), entre unas cosas
y otras puede tardar eso, y claro, no le puedo decir al médico, "oye
cada vez que le hagas algo cierralo, no lo dejes abierto", pq no me va a
hacer caso, es poco probable que 2 médicos traten a la misma persona,
pero sí que puedan pedir opinión y necesiten ver sus historia en
diferentes despachos y demás, así como (poco probable también) que el
médico, esté con el paciente, y la secretaria apuntando cosas por otro
lado, no es muy frecuente, pero podría suceder(y quiero adelantarme a
los problemas)
Así como también usan unos "párametros" que determinan como va o puede
ir la enfermedad,en función de eso, es el tratamiento, etc.
Estos útimos parámetros, si pueden ser modificados a la vez por "x"
médicos, porque son comunes.
Por otro lado, la ficha no es un largo texto, son como 30 tablas de uan
base de datos, y otras 10 tablas de otra BD.
Esto al final, es lo que conforma la historia, en la consulta normal,
puede o no(casi suele ser la primera vez nada mas) usar todas las
tablas, para así generar "la criatura" que es el informe final.:)
Un saludo
Suso
> suso escribió:
>> Hola Rafael, esto es para hospitales, puede haber entorno a los 25
>> usuarios máximo(por ahora), quizás en un futuro 1 año o menos, quizás,
>> muchos mas(como 20 veces).
>> En principio, como es de suponer, sólo debería estar 1 persona como
>> mucho(pero nunca se sabe) accediendo a ese paciente, la historia de ese
>> paciente puede estar bloqueada(trabajando en ella) como 90', de esos 90,
>> cada 5 o 10 puede abrirse una tabla, que son 30 tablas(+/-), no todas se
>> abrirán.
>
> ¿Qué clase de modificaciones se le hacen al registro del paciente? Una
> posible idea sería guardar del lado del cliente los datos, cerrar la
> conexión, dejar que el usuario haga las modificaciones en la aplicación,
> y al momento de guardarlas en la BD haces algo así:
>
> 1. abrir la conexión de nuevo
> 2. comparar los datos existentes en la BD con los que tenías guardados
> en memoria
> 3. si son iguales, entonces hacer un UPDATE simple con los nuevos datos
> 4. si no, debes hacer un "merge" de los cambios.
>
>
> El merge se puede implementar de muchas maneras; por ej. lo más simple
> para el programador sería preguntarle al usuario: "mire, antes tenía
> esto y usted cambió aquí, pero mientras tanto vino otro y cambió acá.
> ¿qué hago?". La otra sería implementar un algoritmo de resolución de
> conflictos; qué algoritmo es bueno va a depender de cada caso. Por ej.
> en el caso de una ficha clínica, una posibilidad sería ver las nuevas
> entradas como "append". (Sin embargo, en este caso considera también la
> posibilidad de que deba implementarse la ficha no como un largo texto al
> cual se le van pegando cosas al final sino como un conjunto de
> registros, con cada una de las adiciones).
>
>
> Esta aproximación tiene la ventaja que no tienes transacciones que duran
> 90'.
>