É o caso que IDENTITY_INSERT só pode ser definido como ON em uma tabela de banco de dados por vez, mas por quê? Como IDENTITYas colunas não são globalmente exclusivas, não consigo pensar em nenhuma situação perigosa que possa ser causada pela inserção de identidades em mais de uma tabela ao mesmo tempo (pelo menos não mais perigoso do que geralmente falsificar IDENTITY INSERT).
IDENTITY INSERT raramente deve ser usado, mas qual é o motivo do limite rígido?
Acho que é para dificultar. Se você pudesse deixá-lo ligado o tempo todo, por que ter um campo de identidade?
Na verdade, existem algumas restrições:
Com base nas restrições relacionadas à conexão, acho que é principalmente para que nunca seja acidentalmente deixado ON.
Imagine se alguém ativou a inserção de ID em uma de suas tabelas, então você não percebeu e uma inserção (normalmente) inválida foi executada que quebrou a integridade do seu campo de ID?
Lembre-se de que os campos de ID podem ter valores duplicados se não houver restrição ou índice exclusivo em vigor...
Meu palpite é que foi uma restrição devido à implementação. Permitir essa configuração em várias mesas era um potencial golpe de desempenho:
Como este é um parâmetro de sessão, permitir que a configuração seja ativada em uma única tabela significa que é simples sinalizar e o ID do objeto da tabela para armazenar na sessão, do lado do servidor. Talvez seja apenas um único inteiro: 0 se nenhum IDENTITY_INSERT estiver ativo e alguma codificação de databaseid + objectid para a tabela.
Permitir que o parâmetro seja definido em várias tabelas dentro de uma sessão significaria que o servidor armazenaria uma lista dinâmica de tais objetos e a verificaria para cada instrução de inserção. Imagine que uma sessão ativa o parâmetro para mil tabelas:
Também suspeito que definir identity_insert on tenha um impacto geral no desempenho do servidor. No sybase havia um " fator de configuração de queima de identidade ", que permitia salvar o valor do contador de identidade de uma tabela para ser salvo apenas de vez em quando (o valor é mantido na memória e gravado no disco de vez em quando e no servidor desligar ). O SQL Server é baseado no mesmo código, então provavelmente tem alguma otimização comparável, mas ativar identity_insert em uma tabela provavelmente restringe o servidor a salvar o valor de identidade para cada inserção, porque senão não pode garantir um tamanho máximo de intervalo. Portanto, se uma sessão causar um impacto no desempenho nas inserções em uma tabela, isso provavelmente é aceitável, mas não se puder causar um impacto no desempenho em todas as tabelas auto_increment no servidor.