ruskofulanito
commented
7 years ago Paciente: se puede querer dar de baja en caso de haber sido ingresado por error por ejemplo (duplicado). El caso ideal sería permitir reasignar los registros dependientes a otro paciente (por ejemplo, di de alta dos Juan Núñez, entonces elijo eliminar uno y si tiene exámenes/visitas se las puedo asignar a otro paciente que elija). Esta resolución puede ser complicada e innecesaria porque podría ser cubierta permitiendo que solamente un administrador de baja de pacientes (no médicos, no secretario) recontra advirtiendo que se van a eliminar todos sus registros dependientes (que sería también el caso de no reasignar a otro paciente en la sugerencia anterior). Dicho esto, coincido con lo propuesto.
Usuario: de acuerdo con lo propuesto.
Localidad: i. Es restrictivo respecto del saneamiento de datos. Ocurre con mucha frecuencia que en un dominio en el que intervienen muchos usuarios sin una coordinación estricta para la política de alta de parámetros, se registren localidades con criterios heterogéneos. Esta restricción que es muy habitual, impediría sanear los datos más tarde. Por ejemplo, podrían tenerse localidades como "C. Casares", "C Casares", "Casares", "Carlos Casares" y la única forma de proceder sería reasignar a mano los datos de los usuarios. ii. Esta propuesta puede ser adecuada si se considera solamente para el alta de nuevos registros, mostrando por ejemplo los pacientes de localidades dadas de baja con su dato original. Tiene el mismo inconveniente respecto del saneamiento de datos que en el punto anterior. iii. Esto me parece adecuado solamente si la localidad por defecto de los pacientes es NULL (lo que no aporta a la estadística), pero la localidad es obligatoria en este momento en el sistema. Me parece mejor la opción de la reasignación a otra localidad (que podría ser 'Otras', depende del uso). Para el caos de la localidad sí propongo establecer una interfaz de reasignación para permitir sanear datos. Es un punto habitualmente conflictivo en este sentido y puede ser positivo para la estadística.
Partido: definitivamente es un problema enorme la cascada. Propongo impedir que se den de baja partidos que tienen localidades. Pero en este caso los datos están más acotados y pueden ser manejables; el usuario puede cambiar de partido las localidades, resolver la baja de las localidades que ya no quiera, y una vez que un partido no tiene localidades entonces sí permitir dar la baja. Como el partido no está directamente relacionado a la entidad fuerte del dominio, entonces se puede tomar esta solución del lado del usuario.
tanoabeleyra
Entidades conflictivas
Paciente: Creería que es poco común que se realice la eliminación de un paciente, por lo que si realmente hubiera algún motivo para hacerlo (legal?, privacidad?), me parece que la baja tendría que ser física. Para esto propongo que se realice una eliminación en cascada de sus exámenes y visitas.
Usuario: Si el usuario no participó en ningún examen/visita (por ej., un secretario), se podría realizar una baja física (caso contrario, baja lógica).
Localidad: Si existe algún usuario que pertenece a esa localidad podríamos (en orden de preferencia personal):
Partido: Me parece que no tiene sentido que haya localidades que no pertenezcan a ningún partido, por lo que opino que la eliminación tendría que ser en cascada (eliminar sus localidades), pero habría que evaluar antes la baja de una localidad (planteada anteriormente) para ver si es viable.