Por que IDENTITY_INSERT ON é permitido apenas em uma tabela por vez?

É o caso de IDENTITY_INSERT só poder ser definido como ON em uma tabela de banco de dados por vez, mas por quê? Como as IDENTITYcolunas 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 perigosa do que geralmente brincar com o IDENTITY INSERT).

O INSERT DE IDENTIDADE raramente deve ser usado, mas qual o motivo do limite rígido?

Eu 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:

• Persiste apenas nessa conexão
• É configurável apenas em uma tabela por conexão

Com base nas restrições relacionadas à conexão, acho que é principalmente para nunca ser acidentalmente ativado.

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 isso foi uma restrição devido à implementação. Permitir essa configuração em várias tabelas foi um possível sucesso de desempenho:

Como esse é um parâmetro da sessão, permitir que a configuração seja ativada em uma única tabela significa que é um sinalizador simples e o ID do objeto da tabela para armazenar na sessão, no lado do servidor. Talvez este seja apenas um único número 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 em uma sessão significaria que o servidor armazenaria uma lista dinâmica de tais objetos e a verificaria para todas as instruções de inserção. Imagine que uma sessão ativa o parâmetro para mil tabelas:

1. Isso significa que o servidor alocou 1000 itens na variável de sessão
2. Isso significa também que o servidor deve verificar a lista dos 1000 itens para cada instrução de inserção nesta sessão.

Além disso, suspeito que o conjunto identity_insert on tenha um desempenho atingido no servidor. Na sybase, havia um " fator de conjunto de gravação 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, portanto, provavelmente possui uma otimização comparável, mas a ativação de identity_insert em uma tabela provavelmente restringe o servidor a salvar o valor da identidade para cada inserção, pois, caso contrário, não pode garantir um tamanho máximo de espaço. Portanto, se uma sessão faz um impacto no desempenho nas inserções em uma tabela, isso provavelmente é aceitável, mas não se ele pode causar o desempenho em todas as tabelas de incremento automático no servidor.