Cita: si hay dos alteraciones de dos usuarios distintos que se solapan y cada uno modifica un dato diferente del mismo registro, las dos alteraciones deberían ser compatibles y, en tu sistema, no lo son; una de las dos, decida lo que decida el usuario no tendrá efecto.
No se que es lo que te estarás imaginando pero todas las alteraciones son compatibles, y ¿si lo que deside el usuario no tiene efecto, para que lo deside? eso es una afirmacion inconsistente.
Considera la tabla productos(codigo, nombre, costo, stock, precio)
Viene el usuario A y abre el producto 1 para editar, ve que el stock figura en 50 y que el precio de venta es $100, deside cambiar el precio de venta a $110.
Mientras eso ocurre, el usuario B realiza un venta de 49 unidades del producto 1.
Cuando el usuario A va a guardar, el sistema detecta que lo que el usuario A va a modificar no es lo que el cree que va a modificar, entonces le dice:
"AVISO: El producto que va a editar fue modificado por el usuario B a las d/m/Y h:i:s, estos son los datos actuales del registro:
Articulo 1
Descripcion
Costo $50
Stock 1
Precio $100
¿Aun asi desea aplicar la edicion?"
El usuario ve que solo queda 1 unidad en el stock y deside que en vez de aumentar el precio lo va a bajar para hacer una rebaja, cancela la modificacion, aplica la rebaja y guarda.
Tambien podria querer aplicar de todas formas el aumento, en ese caso confirmaría la edicion.
Como veras ambos usuarios modifican campos diferentes pero es importante que el usuario confirme la accion.
Tambien guardo en cada registro que usuario fue el ultimo en modificarlo y en los carteles se lo informo, de esta manera si hay una inconsistencia se comunican entre ellos y lo resuelven.
Cita: Y además no has considerado la posibilidad de que se haya el eliminado el registro por otro usuario cuando el primero quiera guardar los cambios. Lo del timestamp no te vale en ese caso.
Es igual que el caso de que alguien lo halla editado, si al hacer el select no me devuelve nada, la fecha de edicion es null y, por definicion, null es distinto de cualquier valor, asi que sabria que el registro fue eliminado porque las fechas son diferentes y la fecha nueva es null.
Tan simple como eso.
Igualmente nunca hago bajas fisicas, todo son bajas logicas por lo que le pregunto al usuario si quiere restaurar el registro y aplicar los cambios o si quiere cancelar la operacion.
Cita: Lo que planteas es una salida cómoda para el programador e incómoda para el usuario. No creo que eso pasara un examen de "usabilidad".
Te equivocas.
Lo que hago es la salida incomoda para el programador y para el sistema pero segura para el usuario. Seria mucho mas facil no preguntar nada y pisar los datos que revertir una transaccion, responder 3 solicitudes asincronicas y realizar 3 verificaciones.
Pasa todos los examenes de usabilidad, la primer regla basica de un sistema para que sea usable es que el usuario sepa lo que el sistema esta haciendo en todo momento.
Si no le avisas al usuario que lo que va a hacer no es lo que el cree que esta haciendo, le estas poniendo trampas, y cuando un usuario cae en una trampa del sistema comienza a perderle la confianza y nunca mas la recuperara o podria ser peor, comenzaría a pensar que el sistema es su enemigo.
Tu haz lo que quieras, he programado sistemas web para empresas multiusuario y jamas he tenido un problema usando esta tecnica, es mas, hasta les parece genial que les salga la advertencia para no meter la pata en las pocas ocasiones en que esto ocurre.
EDITO:
En aplicaciones de escritorio este tema es mas simple, porque la conexion a la base de datos es persistente y hay herramientas como
SELECT FOR UPDATE que te permiten establecer bloqueos de escritura a nivel de fila, pero la web es asincronica, un usuario puede abrir para editar un registro a las 10 de la mañana y guardar la confirmacion a las 5 de la tarde, en ese lapso de tiempo, el sistema no tiene ni idea de que es lo que hizo el usuario, si completo el formulario, si cerro la pestaña, si se desconecto de la red, si se le prendio fuego la oficina, etc. En cambio en aplicaciones de escritorio el bloqueo sigue vivo mientras el programa se encuentre en la pantalla de edicion y todos los demas miembros de la red saben que hay alguien editando ese registro.