Nova semente da coluna de identidade: quando é necessário?

Durante uma das últimas lições da universidade (eu sou estudante), o palestrante nos pediu para desenvolver um banco de dados (MySQL Server, se necessário) e um pequeno aplicativo cliente que consumiria o banco de dados como fonte de dados.

Um dos requisitos era que a coluna de identidade (que é a PK em todas as tabelas) deve ser seqüencial, porque é uma boa prática (conforme palavras do professor). Ou seja, quando a linha da tabela é excluída, sua PK deve ser reutilizada nas inserções subsequentes. Tenho conhecimento médio em RDBMS, PKs e colunas de identidade. Pelo que entendi, essa coluna de identidade é apenas uma maneira de permitir que o DB gere automaticamente PKs ao inserir linhas e nada mais. E o valor da coluna de identidade não deve estar relacionado aos atributos da linha de forma alguma (desde que não seja uma chave natural).

Esse requisito (coluna de identidade estritamente sequencial) era suspeito para mim. Tentei perguntar ao professor o que havia de errado se a identidade não fosse seqüencial (com brechas causadas por exclusões), mas obtive uma resposta muito abstrata como "é conveniente para os usuários e útil para administradores de banco de dados que mantêm o banco de dados". Não há exemplos específicos. O argumento "conveniente para os usuários" parece tolo, porque não tem nenhum significado no domínio comercial.

Portanto, estou curioso para saber se esses motivos são reais? Só consigo pensar em um caso em que é necessária a nova propagação da coluna de identidade - quando o espaço de identidade está esgotado. Mas isso é mais um problema de design quando o tipo de coluna de identidade foi escolhido incorretamente, digamos simples em intvez de bigintou uniqueidentifierquando a tabela contém bilhões de linhas. Suponha que uma coluna de identidade seja um índice em cluster: as falhas na coluna de identidade podem afetar o desempenho do índice? Talvez haja outras razões do mundo real para a nova propagação automática da coluna de identidade após cada exclusão que não conheço?

Desde já, obrigado!

Ou seja, quando a linha da tabela é excluída, sua PK deve ser reutilizada nas inserções subsequentes.

De que universo é seu professor?

Isso é grosseiramente ineficiente. Se você tentar fazer isso, reduzirá suas perspectivas de desempenho em um fator de 10.

Se você precisar de números sem intervalos por motivos de auditoria, construa-os explicitamente, não diretamente das ferramentas de banco de dados. E nunca exclua linhas, mas sinalize-as como "excluídas". Isso aumentará a confusão das consultas, pois elas terão que ignorar essas linhas.

No MySQL, o InnoDB requer a existência de um único PRIMARY KEYpara cada tabela. Mas essa é a extensão do requisito. A chave pode até ser uma string.

Lacunas são uma conveniência para os usuários e DBAs, não um inconveniente.

Posso pensar em um caso em que a falta de pontos seria conveniente - dividindo-se em grupos de 100 linhas por vez. Mas há uma solução alternativa simples usando LIMIT 100,1.

As lacunas têm impacto nulo no desempenho. Isso inclui índices não numéricos. E índices não exclusivos. E índices compostos.

Claro, você pode ficar sem ids. Eu acho que já vi isso acontecer duas vezes em quase duas décadas de uso do MySQL. Também posso me preocupar em ser atingido por um asteróide. Está na minha lista de coisas que me mantêm acordado à noite.

Lacunas ocorrer a partir de (pelo menos): INSERT IGNORE, IODKU, REPLACE, DELETE, ROLLBACK(explícita, ou devido a falha), replicação multi-mestre (incluindo Galera ea replicação do grupo). Deseja realmente sugerir soluções alternativas para esses ?!

Sinta-se à vontade para nos mandar verificar a sanidade de qualquer outra coisa que o professor disser que é suspeito.

A reutilização de um valor de identidade deve, em geral, ser desencorajada. Ou o valor é usado inteiramente internamente; nesse caso, o valor real é irrelevante ou também é usado externamente; nesse caso, a reutilização do valor provavelmente levará a uma identificação incorreta.

No caso óbvio de uma fatura ou número de pedido de compra, eles podem vir facilmente de uma coluna de identidade e ser expostos externamente, mas você nunca iria querer reutilizá-los exatamente por esse motivo. Ambos se referem a transações específicas que você não gostaria de confundir.

Resolver esses problemas pode ser um grande aborrecimento quando as empresas se fundem ou são adquiridas. Criando esses problemas de propósito? Não é sensato.

A reutilização dos valores de ID da PK apresenta problemas e geralmente deve ser evitada.

Primeiro, a implementação de colunas de auto_increment não oferece a garantia de ser sem intervalos. De fato, ocorrerão lacunas se você reverter uma inserção em uma coluna de incremento automático.

Em segundo lugar, o ID do intervalo pode se referir a dados existentes que não foram excluídos (devido a restrições de FK ausentes). Se eles se traduzirem em números de membros comunicados fora do sistema, isso representa riscos potenciais à identidade comercial.

Em terceiro lugar, bigint unsignedos IDs não ficarão por um tempo significativo, mesmo com uma taxa de inserção extremamente alta.

A maior dor com as lacunas está nos auditores que insistem que é uma falha de auditoria. Para os DBAs, eles sabem que existem lacunas e por quê.

Não ecoarei os comentários de todos os outros de que reutilizar uma PK é uma má ideia, mas já deparei com momentos em que uma coluna de identidade precisava ser reintroduzida.

Corrupção do próprio índice PK.

Concedido isso estava usando o MS-SQL e muitos, muitos anos atrás, mas ainda é relevante. Muitos anos atrás, para a empresa em que trabalho, alguém pensou que seria uma boa ideia reutilizar PCs como servidores em mais de 150 locais remotos depois que eles estavam velhos demais para serem usados ​​pelos clientes e depois colocá-los em um armário sem ventilação. Quando não. Porque todos sabemos que uma pilha de computadores inúteis de 10 anos de idade em uma pequena sala com mais de 120 bancos de dados de missão crítica em execução só poderia resultar em coisas boas. Como taxas de falha de 40% e eu repensando minha escolha de carreira. Nós replicaríamos os dados de volta para a sede da corporação, mas mais frequentemente, essas falhas resultariam em coisas ruins acontecendo nos bancos de dados. Uma dessas coisas foi o banco de dados com índices corrompidos que apreenderiam o banco de dados e o processo de replicação. Por duas vezes nesse ótimo ambiente, a única solução para corrigir a replicação foi realinhar os índices e, em seguida, restabelecer a replicação. Substituímos os servidores mais tarde antes de abandoná-los completamente.