registros de dados edição por vários usuários

votos
23

Eu projetei tabelas de banco de dados (normalizados, em um servidor MS SQL) e criou um janelas independentes front-end para um aplicativo que será usado por um punhado de usuários para adicionar e editar informações. Nós vamos adicionar uma interface web para permitir a pesquisa accross nossa área de produção em uma data posterior.

Estou preocupado que, se dois usuários começar a editar o mesmo registro, em seguida, o último a cometer a atualização seria o 'vencedor' e informações importantes podem ser perdidos. Uma série de soluções vêm à mente, mas eu não tenho certeza se eu estou indo para criar uma dor de cabeça maior.

  1. Não fazer nada e esperar que dois usuários nunca vai estar editando o mesmo registro ao mesmo tempo. - talvez nunca happed mas o que se faz?
  2. Rotina de edição pode armazenar uma cópia dos dados originais, bem como as atualizações e, em seguida, comparar quando o usuário tiver terminado a edição. Se eles diferem mostrar usuário e comfirm atualização - Será que exigem duas cópias de dados a serem armazenados.
  3. Adicionar última coluna DATETIME atualizado e verificar se corresponde quando atualizar, se não, em seguida, mostrar as diferenças. - requer nova coluna em cada uma das tabelas relevantes.
  4. Criar uma tabela de edição que registra quando os usuários começar a editar um registro que será verificado e impedir que outros usuários editem mesmo registro. - exigiria pensamento carful de fluxo do programa para evitar impasses e registros de se ficar preso se um usuário cai fora do programa.

Há alguma solução melhor ou devo ir para um desses?

Publicado 03/08/2008 em 22:23
fonte usuário
Em outras línguas...                            


8 respostas

votos
12

Se você espera colisões infrequentes, concorrência otimista é provavelmente a sua melhor aposta.

Scott Mitchell escreveu um tutorial completo sobre como implementar esse padrão:
Implementação de concorrência otimista

Respondeu 03/08/2008 em 22:31
fonte usuário

votos
2

Uma abordagem clássica é como se segue:

  • adicionar um campo booleano, "bloqueado" para cada tabela.
  • definir esta como false por padrão.
  • quando um usuário inicia a edição, você fazer isso:

    • bloquear a linha (ou a tabela inteira se você não pode bloquear a linha)
    • verifique a bandeira na linha que deseja editar
    • se o sinalizador é verdadeiro, em seguida,
      • informar o usuário que não pode editar essa linha no momento
    • outro
      • definir o sinalizador para true
    • liberar o bloqueio

    • ao salvar o registro, defina o sinalizador de volta para falso

Respondeu 01/10/2008 em 09:53
fonte usuário

votos
1

-primeiro criar arquivado (tempo de atualização) para armazenar último registro atualização -quando qualquer usuário selecione o registro salvar Selecionar tempo, comparar entre seleto tempo e campo de tempo de atualização se (tempo de atualização)> (selecionar época) que significa uma outra atualização utilizador deste registro depois selecione registro

Respondeu 14/07/2016 em 11:23
fonte usuário

votos
1

SELECT FOR UPDATE e equivalentes são bons proporcionando-lhe manter o bloqueio para uma quantidade microscópica de tempo, mas para uma quantidade macroscópica (por exemplo, o usuário tem os dados carregados e não pressionado 'salvar' você deve usar simultaneidade otimista como acima. (Que Eu sempre acho que é misnamed - é mais pessimista do que 'último escritor ganha', que normalmente é a única outra alternativa considerada).

Respondeu 01/10/2008 em 06:39
fonte usuário

votos
1

Outra opção é para testar se os valores no registro que você está mudando são as ainda o mesmo como eram quando você começar:

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

(Exibir o campo customer_nm e o utilizador muda)

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' );

Você não tem que adicionar uma nova coluna à tabela (e mantê-lo até à data), mas você tem que criar instruções SQL mais detalhado e passar novos e antigos campos para o procedimento armazenado.

Ele também tem a vantagem de que você não está bloqueando os registros - porque todos nós sabemos que os registros vai acabar por ficar bloqueado quando não deve ser ...

Respondeu 13/08/2008 em 23:32
fonte usuário

votos
1

@ Mark Harrison: SQL Server não suporta essa sintaxe ( SELECT ... FOR UPDATE).

O equivalente SQL Server é a SELECTdica declaração UPDLOCK.

Consulte SQL Server Books Online para obter mais informações.

Respondeu 04/08/2008 em 22:54
fonte usuário

votos
0

Para mim, a melhor maneira eu tenho um lastupdate coluna (timetamp tipo de dados). quando SELECT e UPDATE basta comparar este valor um outro avanço desta solução é que você pode usar esta coluna para rastrear o tempo de dados tem mudança. Eu acho que não é bom se você acabou de criar um colum como isLock para atualização cheque.

Respondeu 24/06/2011 em 08:14
fonte usuário

votos
0

O banco de dados vai fazer isso por você. Olhe "selecione ... para update", que se destina apenas para esse tipo de coisa. Ele lhe dará um bloqueio de gravação nas linhas selecionadas, que você pode então confirmar ou reverter.

Respondeu 04/08/2008 em 03:30
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more