Re: Bloqueo en registro-tabla

Por otro lado, como comento mas abajo, el grueso de las tablas para un
determinado paciente, se usará (segúm me comenta el médico) muuuuy pocas
veces, la primera seguro, las demás visitas, casi siempre es modificar o
ecribir en el informe generado después de tener las pruebas y todo eso,
ésto sería quizzás o bien en la primera o en la segunda visita (creo).

Es un poco "lioso", pero espero haberme explicado bien, el tema de poner
un "bloqueo" propio en una y sólo una de las tablas (pero que sería como
si las bloqueara todas) es evitar porblemas, pero según parece, puee dar
mas problemas de los que soluciona:(
Un saludo
Suso
> 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'.
>>
>
>