Uma chave substituta deve ser exposta a um usuário?

Geralmente, em uma tabela que não possui chave natural, ainda é útil que os usuários possam ter um identificador gerado exclusivamente. Se a tabela tiver uma chave primária substituta (e, nesse caso, você certamente esperaria), essa chave deve ser exposta ao usuário ou outro campo deve ser usado para esse fim?

Um motivo para não expor a chave substituta é que agora você não pode executar operações que preservem o relacionamento entre os registros, mas altere os valores da chave, como certos tipos de exclusão / reinserção, muitos métodos de cópia de dados de um banco de dados para outro, etc.

A principal vantagem de expor a chave substituta é a simplicidade de usar um campo que você possui de qualquer maneira.

Em que circunstâncias é melhor expor diretamente a chave substituta aos usuários?

Você precisa estar pronto para qualquer identificador exposto a usuários / clientes que precisem ser alterados, e alterar a identidade de uma linha em um banco de dados e propagá-la para todas as chaves estrangeiras é apenas pedir para quebrar os dados.

Se os dados não tiverem uma chave comercial natural, você poderá adicionar um campo adicional para um "identificador comercial". Isso deve ser otimizado para os processos para os quais é usado. A entrada do teclado do telefone significa apenas numérico. Por telefone / meios verbais, evite símbolos sonoros semelhantes (B / D, M / N, etc). Você pode até gerar automaticamente uma frase facilmente memorável ("geléia verde").

O efeito disso é que os negócios podem mudar posteriormente como desejam se referir a registros, e a única alteração no esquema de dados é adicionar uma nova coluna para esse estilo de ID ou transformar os IDs já existentes. A alteração não se propaga por todo o banco de dados e você ainda tem um ID (o substituto) que é válido ao longo do tempo.

Em resumo, evitaria expor chaves substitutas aos usuários. Como os comentários apontam, as chaves substitutas quase nunca devem mudar. Por outro lado, as empresas querem mudar tudo. Se a chave substituta for exposta, é apenas uma questão de tempo até que a empresa queira alterá-la.

Como observação lateral, quando digo "expor" aqui, quero dar a chave ao usuário com a expectativa de que ela seja usada diretamente (como ligar para o suporte com o número do pedido).

Em alguns casos, as chaves substitutas são esperadas e fazem sentido para os usuários. Meu exemplo favorito é "número do pedido". O número do pedido não é realmente uma chave natural: uma chave natural pode ser o carimbo de data / hora mais o usuário, ou talvez mais do que isso, se você espera que os usuários gerem mais de um pedido na granularidade do seu carimbo de data / hora.

No entanto, os usuários entendem e esperam a conveniência de um número de pedido. Não há danos e muito valor se você informar aos usuários sobre eles.

Por outro lado, algumas chaves substitutas não fazem sentido para um usuário. Claro, minha companhia de seguros de saúde possui uma chave substituta que me identifica com base no meu ID de membro, data de nascimento, operadora etc. etc. no meu empregador e não são únicos em todo o universo ... Daí a chave substituta na companhia de seguros).

Você só deve expor uma chave substituta se for um GUID / UUID * gerado corretamente. A exposição de chaves substitutas sequenciais é o número 4 nas 10 principais questões de segurança da OWASP.

* Na prática, é melhor supor que não foi gerado corretamente para esses fins, a menos que você saiba que foi criado por um gerador de números aleatórios ou pseudo-aleatórios criptograficamente seguros.

Se uma tabela não tiver uma chave natural, as chaves substitutas permitirão linhas como esta.

surrogate_key  some_name
--
1              Wibble
2              Wibble
...
17             Wibble
...
235            Wibble

Eu chamaria essas chaves artificiais em vez de chaves substitutas, mas essa distinção não é importante para esta pergunta.

Agora, supondo que existam dados importantes referentes a essas chaves substitutas por meio de chaves estrangeiras, como os usuários finais saberão qual linha atualizar se não souberem os valores das chaves substitutas?

Nas palavras do leigo:

• Os substitutos devem estar ocultos do usuário.
• Você deve expor alguma outra chave candidata a negócios ao usuário.
• Se nenhuma outra chave candidata existir, você deverá mostrar o PK. Mas, neste caso, o PK não é considerado um substituto, pois não substitui outra coluna.

você só deve expor um campo a um usuário que forneça informações úteis ao usuário, diretamente ou no relatório de defeitos para você.

por outro lado, você SEMPRE deve expor "chaves primárias substitutas" quando elas forem o principal meio de identificar um registro (simples ou complexo) para uma interação que o usuário executa.

Não importa se você expõe as chaves ou não ao usuário final. Seu aplicativo deve executar a autorização necessária para que simplesmente conhecer um ID de pedido, por exemplo, não possa permitir que eles acessem algo que normalmente não teriam acesso.

advertência: isso pressupõe um aplicativo baseado na Web ou de n camadas, em que a autorização do servidor é possível / viável. Se você tem um aplicativo VB que executa diretamente o sql, isso é uma questão totalmente diferente.