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'. -- Alvaro Herrera Valdivia, Chile Geotag: -39,815 -73,257 "Aprende a avergonzarte más ante ti que ante los demás" (Demócrito) -- TIP 8: explain analyze es tu amigo
