fundo
A abordagem "all-PK-must-be-surrogates" não está presente no Modelo Relacional do Codd nem em nenhum Padrão SQL (ANSI, ISO ou outro).
Os livros canônicos parecem iludir essas restrições também.
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 uma coisa ou duas sobre o design do RDBMS.
O PPDM (Associação Profissional de Gerenciamento de Dados de Petróleo) recomenda os mesmos livros canônicos que:
Use chaves substitutas como chaves primárias quando:
- Não há chaves naturais ou comerciais
- As chaves naturais ou comerciais são ruins (altere frequentemente)
- O valor da chave natural ou comercial não é conhecido no momento da inserção do registro
- As chaves naturais de várias colunas (geralmente várias FK) excedem três colunas, o que torna as junções muito detalhadas.
Também não encontrei uma fonte canônica que diga que as chaves naturais precisam ser imutáveis. Tudo o que acho é que eles precisam ser muito estáveis, ou seja, precisam ser alterados apenas em ocasiões muito raras, se é que alguma vez ocorreram.
Mencionei o PPDM porque essas pessoas também devem saber uma coisa ou duas sobre o design do RDBMS.
As origens da abordagem "todos os substitutos" parecem vir das recomendações de algumas estruturas do ORM.
É verdade que a abordagem permite modelagem rápida de banco de dados , não sendo necessário fazer muitas análises de negócios, mas à custa da capacidade de manutenção e legibilidade do código SQL. Muita previsão é feita para algo que pode ou não acontecer no futuro (a PK natural mudou, teremos que usar a funcionalidade de atualização em cascata do RDBMS) em detrimento da tarefa diária, como ter que juntar mais tabelas em todos os consultar e ter que escrever código para importar dados entre bancos de dados, um procedimento bastante direto (devido à necessidade de evitar colisões de 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 precisa ser suportado com benchmarks. Obviamente, varchars longos e variados não são bons para PK. Mas índices baseados em varchar curto e de tamanho fixo são quase tão rápidos quanto números inteiros.
As questões
- Existe alguma fonte canônica que suporte a abordagem "todos os PK devem ser substituídos"?
- O modelo relacional de Codd foi substituído por um modelo relacional mais novo?
TablenameID
" funciona muito, muito bem. Vi isso trabalhando na prática com um banco de dados de tamanho corporativo com mais de 500 tabelas e, desde então, uso isso para modelagem de banco de dados sempre que possível.