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

14

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?

— psr
fonte

Parte dessa pergunta é que você precisa definir 'usuários'. Os usuários podem ser consumidores de uma API que você expõe ou seres humanos carnudos. A resposta não será a mesma para ambos.

— 12133 James Snell

1

Seres humanos carnudos.

— Psr

Toda situação em que os dados podem ser identificados de maneira diferente deve ter um identificador diferente. Portanto, se um novo sistema se conectar aos seus dados, espere que ele tenha seu próprio PK e adicione-o aos seus dados. A visibilidade para "sacos feios de principalmente água" conta como um 'sistema' para esse cenário. Minha solução preferida é armazenar as chaves e os carimbos de data e hora (adicionar, alterar e excluir) das entidades em uma tabela especial. Dessa maneira, os dados podem ser facilmente distribuídos.

10

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).

— Chris Pitman
fonte

5

Esta resposta não faz sentido. As chaves substitutas nunca são alteradas e você não defendeu a exposição delas aos usuários.

— Robert Harvey

1

Nunca diga nunca. e se o último design levar à consolidação de registros? e se você precisar aumentar o tamanho e converter as identidades?

— DougM

3

@DougM: Em seguida, grave os registros em uma nova tabela consolidada com sua própria chave substituta e mantenha as chaves originais em campos separados na nova tabela (e um campo que identifique a tabela de origem original) como referências, se necessário. Esse tipo de consolidação deve ser extraordinariamente raro, e somente como resultado de um design defeituoso. Repita comigo: Substituto. Chaves. Nunca. Mudança. É por isso que eles são substitutos.

— Robert Harvey

2

@RobertHarvey Concordo que as chaves substitutas nunca devem mudar, e é por isso que acho que elas produzem identificadores externos ruins. Eventualmente, um cliente desejará alterar a forma como se refere a um registro. Nesse ponto, você construiu seu sistema inteiro em torno de chaves substitutas imutáveis ou pensou em um futuro e colocou um nível de indireção entre os identificadores de negócios e as chaves substitutas.

— Chris Pitman

2

@sqlvogel: Tornaria as coisas mais claras se eu usasse o termo "chave primária gerada pelo sistema" em vez de "substituto"? Concordo que você pode querer alterar o algoritmo que gera as chaves substitutas, mas isso não altera sua qualidade fundamentalmente imutável.

— Robert Harvey

4

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).

— Alan Shutko
fonte

Se um usuário entende e espera interagir com ele, ele não é mais uma chave substituta. Chaves substitutas são definidas como sem significado comercial. Só porque é um número de identificação não significa necessariamente que é um substituto. Além disso, "alguma chave substituta que me identifica com base no meu ID de membro, data de nascimento [...]" não faz sentido. Você está dizendo que a chave substituta (que não tem significado comercial) o identifica com base em coisas que poderiam compor uma chave natural?

— precisa

Freqüentemente, o que acontece é que você recebe um número de identificação do funcionário para que, no sistema do funcionário, você se diferencie de outras pessoas com o mesmo nome. No seu cartão de seguro, ele pode listar a sua empresa e o ID do funcionário. Mas a empresa de seguro de saúde geralmente gera seu próprio ID interno que pode ser usado em todos os seus sistemas, em vez de usar o nome, data de nascimento e IDs de funcionários que recebe do seu empregador. Essas chaves geradas são substitutas ou chaves naturais? Depende de quem você perguntar (verifique 2 definições alternativas em en.wikipedia.org/wiki/Surrogate_key )

— Alan Shutko

1

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.

— Peter Taylor
fonte

2

Não está claro em sua resposta como um GUID melhora a segurança.

— Robert Harvey

1

@RobertHarvey - Presumo que não sejam sequenciais e, portanto, não podem ser adivinhados.

— Bobson

1

segurança.stackexchange.com

— q

@RobertHarvey, esclarecido.

— 22613 Peter Peter

1

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?

— Mike Sherrill 'Recolha de gatos'
fonte

É um pouco contraditório rotular a coluna "surrogate_key", mas diga que são "chaves artificiais em vez de chaves substitutas". Se você estiver chamando essas chaves artificiais porque elas não têm significado comercial e servem apenas como identificadores exclusivos, essa chave deve ser naturalizada (exposta) e uma nova chave substituta deve ser criada. ou seja, renomeie a surrogate_key naturalizada para algo com significado comercial, exponha-a aos clientes e crie uma nova coluna semelhante para ser a verdadeira substituta para operações internas. Menos que o ideal, mas ainda melhor do que expor um verdadeiro substituto.

— Kyle McVay

@KyleMcVay: Não é contraditório. Ele honra o significado de substituto , cuja idéia essencial é "substituir". Uma chave substituta substitui uma chave natural. (A teoria codd e relacional em geral usa chave substituta nesse sentido.) Uma tabela que não possui chave natural não pode ter uma chave substituta nesse sentido. Mas pode ter um valor arbitrário usado em vez de qualquer outra coisa. Isso é o que eu chamaria de chave artificial.

— Mike Sherrill 'Cat Recall'

Suas definições não são imprecisas, mas acho que a chave substituta assumiu um significado extra específico do setor além da palavra substituto . Se você vai expor uma chave para um cliente, eu diria que essa chave agora tem significado comercial; foi naturalizado e agora deve ser considerado parte da entidade que representa. Por essa lógica, não existe uma chave substituta exposta. Se você vai expor uma chave artificial, ela não é mais uma chave substituta e você precisa de uma nova.

— precisa

0

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.

— Tulains Córdova
fonte

Por que o PK deve ser mostrado? Eu acho que é a minha pergunta - se uma PK gerada automaticamente é chamada corretamente de chave substituta é tangencial.

— psr

1

@psr O título da sua pergunta diz " chaves substitutas sempre serão expostas". Eu disse não. Mas você tem que mostrar outra chave. Se nenhuma outra chave existir, você deverá mostrar a única chave que possui. Claramente, esclareço que, nesses casos, a chave não é realmente um substituto porque não substitui nenhuma outra coluna.

— Tulains Córdova

A questão é se você deve adicionar uma coluna ou mostrar a chave que possui.

— psr

@psr reformulei minha resposta para torná-la mais clara.

— Tulains Córdova

1

Acho que isso é uma distinção materialmente insignificante. Se sua regra é que toda tabela tenha uma chave artificial (qual é a minha) e que apenas as chaves artificiais participem das junções (que também é meu princípio), a noção de que uma chave é uma substituta porque outras chaves podem ser disponível é irrelevante.

— 9788 Robert Harvey

0

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.

— DougM
fonte

0

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.

— GrandmasterB
fonte

Que tal não poder inserir e excluir registros, preservando os relacionamentos de chave estrangeira, conforme mencionado na pergunta?

— psr

O que isso tem a ver com a exposição da chave ao usuário? Talvez eu não entenda seu uso do termo 'expor'. Estou trabalhando com a suposição de que você quer dizer 'capaz de ser visto pelo usuário'.

— GrandmasterB