Muito polêmico esse post, porém é uma realidade do Seculo 21.

Devido a polêmica, estou editando o post com esse recado abaixo:

“Cada aplicação tem suas necessidades e comportamento, ou seja, não existe certo ou errado!”. 

Que bom que seja assim, temos N possibilidades de desenvolvimento para cada tipo de sistema.

Hoje em dia a maioria dos sistemas online tem uma alta volumetria de dados, chegando em Bilhões de registros cadastrados no Banco de dados, com isso chegando no número máximo suportado.

Para tornar seu sistema escalável é aconselhável o uso do tipo cadeia de caracteres (String),  devido a possibilidades quase infinitas de combinações.

Para entender a infinidades de possibilidades, acesse o site abaixo e eu duvido você acessar o site mais de uma vez e repetir o UUID:

https://www.uuidgenerator.net/

Há 1% de chance de colisão se gerar 2.600.000.000.000.000.000 UUID, ou seja, quase zero.

Exemplo de UUID:

9ac73f3c-43d3-4795-b347-66cfd7cddba1

Obs. Lógico que conheço o tipo Bigint do SQL Server ou LONGINTEGER do Oracle que suporta 2^63-1.

Tem alguma dúvida ou sugestão? Deixe nos comentários!

 

Participe da conversa! 3 comentários

  1. O artigo é muito “raso”, não leva em considerações fatores mais importantes nas aplicações do dia a dia, como o fato de que tipo de dados númericos serem mais rápido do que string, de que existe alternativas maiores para a chave primária e de que provavelmente a maioria das aplicações hoje em dia não devem terem tantos registros e se tiverem provavelmente o problema será outro muito antes de ser a falta de chaves.
    É claro que aplicações massivas podem terem necessidades reais de chaves maiores, porém provavelmente usar strings como pk não vai ser a única solução.

    Também é importante considerar que operações mais “complexas” se tornam mais lentas, como query’s que comparam os valores da PK dinamicamente ou processo de busca quando banco estiver massivo.
    Se a aplicação for voltada a performance na hora da inserção, também causa problemas, já que é necessário criar a PK manualmente anteriormente para depois informar no banco.

    E por último é falado em 1% de chance de colisão… bem usando um tipo númerico você tem 0% de chance de colisão.
    É claro que é possível diminuir ainda mais a chance de colisão melhorando o sistema de gerar as PKs, porém eventualmente com um banco massivo a gente encontra um problema muito sério.

    Basicamente quanto maior o número de dados e menor a poll de PKs disponíveis a serem geradas mais a chance de colisão, com isso temos que implementar algoritimos de checagem de colisão
    para gerar novavemente uma PK, porém quanto maior o banco, maior o número de colisão, enventualmente o processo pode entrar em loop gerando sempre colisões.

    De forma geral eu recomendaria ao autor pesquisar um pouco mais a real necessidade de se usar strings como tipo da PK, porque dependendo da aplicação é necessário, porém no motivo apresentado acima é falho.

    Um exemplo é um endpoint publico com informações sensitivas, como uma API de pedidos com o número do pedido como inteiro Ex: site.com/pedido/10

    Nesse caso é estranho a gente passar o ID de forma inteira, porque qualquer um pode descobrir novos pedidos e se aproveitar dos dados.
    Então nesse caso UUID é mais recomendado.

    Também é importante verificar que caso o problema seja quantidade de registros, talvez banco de dados diferentes possam solucionar o problema.
    Também já vi em diversos sistemas massivos o uso de tabelas diferentes (porém com estruturas iguais) para os mesmos tipos de dados, porém com separações de acordo com a lógica do negócio.

    Responder
  2. Sobre tipo numérico ser mais rápido que string, você está enganado. Estude um pouco sobre como são criado os índices no banco de dados.

    Responder

Deixe um comentário

CATEGORIA

Banco de Dados, Geral

Tags

, , , ,