Aquí podría ser tu PUBLICIDAD


Edición de registros de la base de datos por múltiples usuarios

votos
23

He diseñado tablas de bases de datos (normalizadas, en un servidor MS SQL) y he creado una interfaz de usuario independiente para una aplicación que será utilizada por un puñado de usuarios para agregar y editar información. Añadiremos una interfaz web para permitir la búsqueda en nuestra área de producción en una fecha posterior.

Me preocupa que si dos usuarios comienzan a editar el mismo registro, el último en comprometer la actualización sería el ganador y se podría perder información importante. Me vienen a la mente varias soluciones, pero no estoy seguro de si voy a crear un mayor dolor de cabeza.

  1. No haga nada y espere que dos usuarios nunca editen el mismo registro al mismo tiempo. - Puede que nunca haya pasado, pero ¿y si sucede?
  2. La rutina de edición podría almacenar una copia de los datos originales, así como las actualizaciones y luego comparar cuando el usuario haya terminado de editar. Si difieren, muestra la actualización del usuario y de la confirmación : se requerirán dos copias de datos para almacenar.
  3. Agregue la última columna DATETIME actualizada y verifique que coincida cuando actualicemos, de lo contrario, muestre las diferencias. - requiere una nueva columna en cada una de las tablas relevantes.
  4. Cree una tabla de edición que se registre cuando los usuarios comiencen a editar un registro que será verificado y evitará que otros usuarios editen el mismo registro. - requeriría una cuidadosa reflexión del flujo del programa para evitar bloqueos y que los registros se bloqueen si un usuario se bloquea fuera del programa.

¿Hay alguna solución mejor o debería elegir una de estas?

Publicado el 03/08/2008 a las 22:23
fuente por usuario Swinders
En otros idiomas...        العربية       

8 respuestas

votos
12

Si espera colisiones infrecuentes, la Concurrencia optimista es probablemente su mejor opción.

Scott Mitchell escribió un tutorial completo sobre la implementación de ese patrón:
Implementación de la simultaneidad optimista

Respondida el 03/08/2008 a las 10:31
fuente por usuario Dave Ward


Aquí podría ser tu PUBLICIDAD


votos
2

Un enfoque clásico es el siguiente:

  • agregue un campo booleano, "bloqueado" a cada tabla.
  • establezca esto como falso por defecto.
  • cuando un usuario comienza a editar, usted hace esto:

    • bloquear la fila (o toda la mesa si no puedes bloquear la fila)
    • revisa la bandera en la fila que deseas editar
    • si la bandera es verdadera, entonces
      • informar al usuario que no pueden editar esa fila en este momento
    • más
      • establecer la bandera en verdadero
    • suelta el candado

    • al guardar el registro, establezca la bandera en falso

Respondida el 01/10/2008 a las 09:53
fuente por usuario AJ.

votos
1

-En primer lugar crear presentado (tiempo de actualización) para almacenar último registro de actualización -cuando cualquier usuario seleccionar Guardar registro de selección de tiempo, comparar entre Seleccionar campo de hora y tiempo de actualización si (tiempo de actualización)> (seleccionar el tiempo) que significa otra actualización de este registro de usuario después seleccione grabar

Respondida el 14/07/2016 a las 08:23
fuente por usuario mohamed elbagory

votos
1

SELECT FOR UPDATE y los equivalentes son buenos siempre que mantenga el bloqueo durante un tiempo microscópico, pero para una cantidad macroscópica (por ejemplo, el usuario tiene los datos cargados y no ha pulsado 'guardar', debe utilizar la concurrencia optimista como se indicó anteriormente. Siempre pienso que tiene un nombre equivocado: es más pesimista que el "último escritor gana", que generalmente es la única alternativa considerada).

Respondida el 01/10/2008 a las 06:39
fuente por usuario Ian W

votos
1

Otra opción es probar que los valores en el registro que está cambiando siguen siendo los mismos que cuando comenzó:

SELECT 
    customer_nm,
    customer_nm AS customer_nm_orig
FROM demo_customer
WHERE customer_id = @p_customer_id

(muestre el campo customer_nm y el usuario lo cambia)

UPDATE demo_customer
SET customer_nm = @p_customer_name_new
WHERE customer_id = @p_customer_id
AND customer_name = @p_customer_nm_old

IF @@ROWCOUNT = 0
    RAISERROR( 'Update failed: Data changed' );

No tiene que agregar una nueva columna a su tabla (y mantenerla actualizada), pero tiene que crear más sentencias SQL detalladas y pasar campos nuevos y viejos al procedimiento almacenado.

También tiene la ventaja de que no está bloqueando los registros, porque todos sabemos que los registros terminarán bloqueados cuando no deberían ...

Respondida el 13/08/2008 a las 11:32
fuente por usuario Guy

votos
1

@ Mark Harrison: SQL Server no admite esa sintaxis ( SELECT ... FOR UPDATE).

El equivalente de SQL Server es la SELECTsugerencia de la declaración UPDLOCK.

Consulte los libros en línea de SQL Server para obtener más información.

Respondida el 04/08/2008 a las 10:54
fuente por usuario karlgrz

votos
0

En mi caso, la mejor manera que tengo un lastupdate columna (timetamp tipo de datos). cuando se seleccione y actualizar simplemente comparar este valor otro avance de esta solución es que se puede utilizar esta columna para determinar la hora de datos tiene cambio. Creo que no es bueno si sólo crea una colum como isLock para la actualización del registro de entrada.

Respondida el 24/06/2011 a las 08:14
fuente por usuario Linh danh thue

votos
0

La base de datos hará esto por ti. Mira "seleccionar ... para actualizar", que está diseñado solo para este tipo de cosas. Le dará un bloqueo de escritura en las filas seleccionadas, que luego puede confirmar o revertir.

Respondida el 04/08/2008 a las 03:30
fuente por usuario Mark Harrison