Início / dba / Perguntas / 12551
Accepted
codecool
Asked: 2012-02-10 07:21:27 +0800 CST

Prós e contras de verificar se o valor existe para uma coluna exclusiva ou permite que o banco de dados gere um erro exclusivo ao inserir

  • 772

Enquanto escrevia uma consulta outro dia, um pensamento me ocorreu e ficou preso em minha mente.

O que é preferível, primeiro verificar se existe um valor para uma coluna exclusiva e, em seguida, inserir ou inserir e deixar o db aumentar o erro de restrição exclusiva? Será que isso importa?

Editar: conforme sugerido abaixo na resposta de que esse problema depende do banco de dados, estou adicionando a tag postgresql.

postgresql performance

2 respostas

  1. Deixe o banco de dados gerar um erro.

    Testar primeiro não é seguro para simultaneidade porque você obterá uma colisão eventualmente porque 2 threads podem passar por "NÃO EXISTE" e ambos tentarão gravar. Isso se aplica às estratégias de bloqueio "READ COMMITTED" e MVCC/Snapshot.

    Você pode usar dicas de bloqueio para forçar o isolamento, mas reduz o desempenho.

    Eu chamo isso de padrão JFDI (link SO). Para "atualizar se existir", veja aqui: Precisa de ajuda para solucionar problemas do Sql Server 2005 Cenário de impasse . Estes são SQL Server. O MySQL tem INSERT IGNORE que lida com isso graciosamente. Não tenho certeza sobre o resto

    • 8
  2. Best Answer

    Não acho que sua pergunta seja realmente independente de banco de dados. A resposta certa pode depender dos detalhes da implementação, que podem variar de fornecedor para fornecedor e mudar com a próxima versão. Eu testaria em simultaneidade antes de escolher qualquer abordagem em qualquer RDBMS.

    No momento, no SQL Server 2008 R2, estou usando o seguinte:

    1. Baixa simultaneidade e baixa quantidade de modificações. Para salvar uma única linha, serializo usando sp_getapplock e uso MERGE. Eu estresso o teste sob alta simultaneidade para verificar se funciona.

    2. Maior simultaneidade e/ou volume. Para evitar a simultaneidade e aumentar o desempenho, não salvo uma linha por vez. Acumulo alterações em meu servidor de aplicativos e uso TVPs para salvar lotes. Ainda assim, para evitar problemas relacionados à simultaneidade, serializo usando sp_getapplock antes do MERGE. Mais uma vez, insisto no teste sob alta simultaneidade para verificar se funciona.

    Como resultado, temos um bom desempenho e zero problemas relacionados à simultaneidade na produção: sem deadlocks, sem violações de restrições únicas/PK, etc.

    • 3

relate perguntas