Código CRC32 como ID [Dúvida Sanada]

[Iwasa]

Olá caros colegas, tenho cá uma dúvida, não sei se é uma dúvida coletiva, mas gostaria de saber qual é a possibilidade de um código CRC32 codificado com o campo de código(5digitos (modelo("00000" formato caracter) + nome(50 caracteres(subtraindo espaços em branco à direita dos 50 caracteres)) + data(10 caracteres (contando barras)) + time (8 caracteres (contando ":") ser duplicado ou ter outro código repetido?

Detalhe: Data e hora são do momento antes de ser gravado em DBF. no módulo de Inclusão de clientes.
o Codigo CRC32 é gerado uma única vez no momento antes da Inclusão, mesmo sendo possivel alterar a data de Cadastro, não é gerado o código novamente.

Pois estou a utilizar esse código como indice de arquivo morto, ou seja, cadastro de clientes excluidos para futuras consultas e seus movimentos, pois o sistema reaproveita os codigos excluídos da tabela de cliente, e este codigo unico é relacionando aos seus movimentos. Contando que um mesmo cliente poderia ter mais de 1 cadastro, claro que mudaria o codigo do cliente, mas a longo prazo o mesmo codigo do cliente se repetiria várias vezes no arquivo morto, muitas vezes com pessoas diferentes com nomes iguais e vários outros motivos..., pois entao, codifiquei codigo do cliente+nome+data+hora.
E recentemente me surgiu esta dúvida, apesar da probabilidade de se repetir seja muito remota.
Desde já agradeço se alguém puder esclarecer esta dúvida.

[Maligno]

A possibilidade de gerar um código igual, o que é chamado de "colisão", não é muito grande, nem muito pequena. Eu diria que é pequena, em virtude da "largura" dos dados ser sempre a mesma. Acredito que não haja motivos para muita preocupação. Mas isso não quer dizer que Murphy vá esquecer que você existe. ))

Eu uso CRC32 em geração de códigos de identificação, como no seu caso. Pra evitar o pior, dentro de uma malha eu gero o código e verifico se ele já existe. A malha se repete até que seja gerado um código original. Nunca testei, mas duvido que um dia tenha chegado a executar essa malha duas vezes. Mas fica a dica.

[Iwasa]

Isso mesmo caro colega Maligno, é um código único de identificação como disse, eu diria que é muito remota, pelo fato da sequencia de digito CRC32 ser do tipo Hexadecimal indo de 0 a 16 digitos, então, se não me falha os cáculos seria (8^16)*(largura dos dados), mas como os dados são variantes, então ficou essa dúvida, pois de maneira alguma pode exisitir um código "colidido" ou "igual".

Mas a sua dica foi muito importante, não tinha pensado em verificar se o código já exista, mas isso é um ponto a mais para coibir uma futura "falha" na geração do código...

Vou implementar uma rotina de verificação na tabela de clientes e no arquivo morto, pois, logo que o cliente seja deletado, será automaticamente repassado ao arquivo morto e todos os seus movimentos identificado pelo código CRC32, formando assim um histórico do cliente, este é o motivo pelo qual o código CRC32 não pode repetir o mesmo codigo, pois poderia comprometer o movimento de outros clientes..., já que o código do cliente de 5 digitos com zeros à esquerda se repetirá pelo reaproveitamento de codigo(o codigo somente se repetirah no arquivo morto), então nao poderia contar com o critério do codigo do cliente de 5 digitos, contando que esse cliente poderia voltar num futuro e haveria a coincidencia dele pegar o mesmo codigo, são vários motivos como disse antes e nem vou citar mais pois o post ficaria muito extenso. Esse foi o motivo de utilizar o CRC32 como identificador único. Já o md5 tb poderia ser utilizado, mas sua string é muito longa.
Mas obrigado caro Maligno pela dica preciosa...

[Iwasa]

Caro Maligno, gostaria de um conselho seu, a longo prazo esse arquivo-morto pode ficar muito extenso pra averiguação do codigo CRC32, e ter q varrer a procura dos codigos em duas tabelas ficaria um tanto lento se comparado a longo prazo, pela proporção do tamanho... e tb não gostaria de deixar o arquivo morto em memoria, carregar somente pra consultas especiais.
Por esta razão, não seria melhor criar um banco de dados com todos os códigos CRC32 cadastrados em uma tabela?
Nesta tabela constaria o campo CRC32, e campo CodeSign. O campo CodeSign seria um sinalizador para saber o status do código CRC32 se está na tabela Clientes ou no arquivo-morto, utilizando sinais como "+" ativo na tabela clientes e "-" para arquivo morto...
Seria vantajoso criar essa tabela?
No aguardo, obrigado desde jah )

[Maligno]

Bom, quando eu disse que verificava o código gerado, eu quis dizer que uso um índice (NSX), que é muito rápido. Minha sugestão, portanto, é exatamente essa: crie um índice exclusivo para esse código. Até em NTX (não sei qual RDD você usa) vai funcionar muito bem, já que a chave é das mais simples.

[Iwasa]

Olá maligno obrigado pela sugestão.
Eu utilizo o RDD CDX hoje, antes utilizava NTX, mas vi grandes vantagens em utilizar RDD CDX e migrei para esta.
A verificação por indices é extramamente rápida.
Mas como no meu caso, vou ter duas tabelas em que o CRC32 não poderá se repetir.
Então estava pensando em criar uma tabela CRC32 como fonte de pesquisa sendo nela apenas incrementada os codigos pelo modulo de inclusão.
E caso o cliente seja excluida manteria-se o código para futura pesquisa e no campo CodeSign um sinalizador para verificar se está ou não na tabela de Clientes...
E o campo CRC32 na tabela clientes está indexada e no arquivo-morto tb será indexada tb para consultas neste banco de dados para procura dos movimentos.
No caso do cadastro do cliente ser passado para o arquivo morto, o mesmo será excluida da tabela de clientes, ficando somente no arquivo-morto.
Daí minha idéia de criar uma Tabela para os códigos CRC32.
Não sei se estou fazendo confusão ou algo desnecessário, pois a preocupação é tanta. Porque os dados são de extrema importância.
Muito obrigado por enquanto Maligno, suas sugestões são preciosas.

[Maligno]

Pelo que entendi são duas tabelas: a normal e a "morta". É isso? Se for, em seu lugar eu geraria os códigos CRC32 indistintivamente. Afinal, código é sempre código. Meus códigos de acesso, em qualquer uma das dezenas de tabelas que tenho, são todos aleatórios. Não uso dados de tabela. Minha probabilidade de colisão, acredito, é maior do que no seu caso, já que a largura dos seus dados é fixa. Mas ainda assim, pelo método de usca contínua, consigo um código único. Pra evitar uma colisão, acrescento ao código aleatório o que se chama nesse ramo de "salt" (sal). Ou seja, uma string identificadora que é adicionada à string base do código. Exemplo: "CadCli" para cadastro de clientes, "NotSai", para notas fiscais de saída, etc... Acho que no seu caso, havendo duas tabelas, você poderia usar esse salt para criar uma distinção entre as tabelas. Por mais parecidos que sejam os dados, seria praticamente impossível obter para uma tabela um código que já existe em outra. No entanto, nada impede que você também faça uma busca pelo CDX das duas tabelas, já que é uma operação rápida.

Aliás, explicando: eu uso um código aleatório (random) para gerar uma string de identificação. Não lembro agora do tamanho, mas uma malha me obtém uma string com a largura de uns 40 dígitos. Não bastasse a quase impossibilidade de repetição, a ela ainda acrescento o salt que representa o tipo da tabela, para criar mais uma distinção, conforme expliquei acima. E finalmente, para "encurtar" a string, gero o CRC32 dessa string. Funciona maravilhosamente. Antes eu era do time que usava as tabelas de código, do tipo "ultimo+1". Mas essa técnica dos códigos aleatórios é bem melhor.

[Iwasa]

Caro Maligo, sim são duas tabelas, com a mesma estrutura.
A "morta" será onde vou guardar os registros apagados da tabela CLIENTES para consultas posteriores.

E uma outra "morta" será criada para a tabela de MOVIMENTO deste cliente que foi deletado da tabela CLIENTES, ambos contendo o código CRC32.
Então utilizarei para pesquisa este ótimo código CRC32 como índice de filtragem, que me veio bem a calhar, já que o código de clientes terão vários repetidos.
Fica prático pesquisar e sem margem de erro. Por isso não pode haver "colisão".

O seu esquema me parece ótimo, e este recurso do "salt" é bem interessante na criação dos códigos. A probabilidade de colisão diminui drasticamente.

No meu caso, o único campo de geraçao de CRC32 que não é fixa é o campo do NOME do Cliente, pois eu retiro os espaços em branco da direita com RTRIM().

Mas quanto ao código CRC32 eu entendi agora perfeitamente ) e vou utilizar suas dicas.
Maligno mais uma vez muito obrigado pelas suas dicas. :{

[Maligno]

Não por isso. Mas a título de informação: se precisar de outro hash além do CRC32, tenho também o MD5 no meu site. É parecido, porém maior (32 dígitos) mas com menor colisão. Acho que nem seria o caso, até porque o CRC32 resolve o caso.