Estive investigando o uso de GUIDs como chaves primárias em bancos de dados. Até agora, os profissionais parecem superar os contras. No entanto, vejo um ponto em que os GUIDs podem não ser o que eu quer

No meu aplicativo, os usuários devem poder identificar objetos com base em um ID amigável. Por exemplo, se eles desejam obter um produto específico sem digitar o nome completo, podem usar o ID do produto. GUIDs não são fáceis de lembrar para algo assim.

A solução em que estou pensando é usar um GUID e um número inteiro com auto incremento. O GUID seria a chave primária da linha, enquanto o número inteiro com incremento automático seria um índice usado pelas funções de filtragem do aplicativo. Todas as instruções SQL SELECT, UPDATE, DELETE usariam o GUID, no entant

A principal razão pela qual desejo usar GUIDs é evitar conflitos ao mesclar dois bancos de dados. Se os bancos de dados 1 e 2 tiverem um produto 2, o script do importador precisará alterar o ID e todas as chaves estrangeiras referentes a ele. Com os GUIDs, preciso alterar apenas o ID amigável na própria tabela, enquanto as chaves estrangeiras usariam o GUID exclusivo para cada registro importado e, portanto, funcionarão sem modificaçõe

ntão, minha pergunta é: existem problemas importantes (além do tamanho do campo GUID e da fácil fragmentação da página) em ter um índice inteiro autoincremento e uma chave primária GUI