Existe uma fonte canônica que apoia “todos os substitutos”?

Question

Fundo

O "todos-PK-devem-ser-substitutos" abordagem não está presente em Modelo Relacional de Codd ou qualquer Padrão SQL (ANSI, ISO ou outro).

Os livros canônicos também parecem escapar dessas restrições.

O próprio esquema de dicionário de dados da Oracle usa chaves naturais em algumas tabelas e chaves substitutas em outras tabelas.Menciono isso porque essas pessoas devem saber algumas coisas sobre design de RDBMS.

PPDM (Professional Petroleum Data Management Association) recomenda os mesmos livros canônicos:

Use chaves substitutas como chaves primárias quando:

1. Não existem chaves naturais ou comerciais
2. As chaves naturais ou comerciais são ruins (mudam com frequência)
3. O valor da chave natural ou comercial não é conhecido no momento da inserção do registro
4. Chaves naturais de múltiplas colunas (geralmente várias FK) excedem três colunas, o que torna as junções muito detalhadas.

Além disso, não encontrei fonte canônica que diga que as chaves naturais precisam ser imutáveis. Tudo o que descobri é que eles precisam ser muito estáveis, ou seja, precisam ser trocados apenas em ocasiões muito raras, ou nunca.

Menciono o PPDM porque essas pessoas também devem saber algumas coisas sobre design de RDBMS.

As origens da abordagem “todos os substitutos” parecem vir de recomendações de algumas estruturas ORM.

É verdade que a abordagem permite modelagem rápida de banco de dados por não ter que fazer muita análise de negócios, mas às custas da manutenção e legibilidade do código SQL.Muita previsão é feita para algo que pode ou não acontecer no futuro (o PK natural mudou, então teremos que usar a funcionalidade de atualização em cascata do RDBMS) às custas de tarefas do dia-a-dia, como ter que juntar mais tabelas em cada consulta e ter que escrever código para importar dados entre bancos de dados, um procedimento muito direto (devido à necessidade de evitar colisões PK e ter que criar tabelas de estágio/equivalência antecipadamente).

Outro argumento é que os índices baseados em números inteiros são mais rápidos, mas isso deve ser suportado por benchmarks.Obviamente, varchars longos e variados não são bons para PK.Mas os índices baseados em varchar curtos e de comprimento fixo são quase tão rápidos quanto os números inteiros.

As questões

- Existe alguma fonte canônica que apóie a abordagem "todos os PK devem ser substitutos"?

- O modelo relacional de Codd foi substituído por um modelo relacional mais recente?

Answer 1

"Todos os PKs são substitutos" não é uma estratégia muito sólida e certamente não é aquele em que você provavelmente encontrará uma fonte "autorizada" para.

Em primeiro lugar, pense no que se entende por "chave primária" neste contexto.No modelo relacional não existem chaves "primárias" - ou seja, nenhuma chave que seja fundamentalmente diferente de qualquer outra chave da mesma tabela.Em princípio, todas as chaves em um banco de dados relacional podem e desfrutam do mesmo status e têm os mesmos recursos e funções, exceto na medida em que o projetista do banco de dados escolha o contrário.A seleção de qualquer chave em uma tabela com múltiplas chaves é, portanto, essencialmente arbitrária (essa foi a palavra usada por E.F.Codd), subjetiva e puramente psicológica (a visão de Chris Date, colega e colaborador de Codd).A menos que seja explicado que distinção está sendo feita entre uma chave "primária" e qualquer outra chave, é, portanto, bastante sem sentido e sem mérito algum afirmar que tal chave "deveria" ou "deve" ser qualquer coisa.

Em segundo lugar, o argumento tem muito pouco a ver com índices, que são um recurso de armazenamento físico.As chaves são uma questão lógica, não física, e não há razão absoluta para supor que as considerações de armazenamento de uma chave "primária" sejam ou devam ser diferentes de outras chaves (consulte o parágrafo anterior).Poderíamos razoavelmente assumir que quaisquer que sejam as estruturas de armazenamento usadas, a sobrecarga de armazenamento será, em certa medida, maior com uma chave substituta do que sem essa chave, mas como sempre a melhor resposta aqui é "depende".As decisões de armazenamento devem ser tomadas caso a caso e regras gerais pouco ajudam.

Em terceiro lugar, de um lógico ponto de vista, a exigência absoluta de uma chave substituta faz muito pouco sentido.O requisito para uma chave natural é exatamente o mesmo, com ou sem substituto.A necessidade de que a informação seja identificável no domínio do discurso (ou seja,com uma chave natural, também conhecida como "chave comercial", "chave de domínio") é a mesma.Sim, as chaves podem precisar ser atualizadas, mas às vezes essa é a natureza das coisas.Adicionar um substituto por si só não torna necessariamente as atualizações importantes mais fáceis de manusear e, às vezes, pode torná-las mais difíceis.

Answer 2

As chaves primárias e estrangeiras não precisam ser legíveis. Sua finalidade é manter a estrutura relacional interna do banco de dados, para não ser lida por um humano.

Naturalmente, se houver uma chave natural apropriada que nunca alterar (eu reivindico estes são tão raros quanto os dentes de galinha ou trevos de quatro folhas, mas ...), você pode usar isso, e alguns clientes farão aquele de suas necessidades.

Mas por que adicionar a complexidade adicional a um sistema de banco de dados, para um benefício pouco apreciável? As chaves primárias de substitutos são geradas pelo sistema, garantidas para serem únicas, garantidas para nunca mudar, e são o mesmo tipo de dados para todas as tabelas. Eles terão o mesmo comportamento confiável em todas as circunstâncias.

Se você está procurando um recurso canônico que suporta essa prática, você não encontrará um. Há tantos designers do outro lado do corredor que irá defender violentamente seu uso de chaves naturais e compósitos com índices agrupados como chaves primárias, e todos os recursos canônicos dizem que é a escolha do designer.

veja também
http://en.wikipedia.org/wiki/surrogate_key