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'.
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majord...@postgresql.org)
