SQL Server: conselho de chaves primárias para meu whitepaper necessário

Estou cansado de explicar a cada novo desenvolvedor júnior em nossa equipe de P&D por que ele deve usar chaves primárias e como fazer isso. Então decidi escrever um pequeno whitepaper, que todo novo desenvolvedor deveria ler. Aqui está o rascunho dele.

AVISO LEGAL:

1. Eu sei e entendo a diferença entre índice clusterizado e chave primária
2. Na pergunta a seguir PRIMARY KEY significa PRIMARY KEY CLUSTERED, e SEM PRIMARY KEY significa SEM PK E CLUSTERED INDEX
3. Observe que é um whitepaper para programadores juniores e não SQL
4. Todas as coisas que eles fazem - revisadas antes de entrar no ramo principal de desenvolvimento
5. Não vou explicar a eles - quando haverá benefício em usar o índice clusterizado e a chave primária NÃO clusterizada - caso contrário, cairei no inferno das otimizações prematuras

A questão é - o que mais devo adicionar ao documento? Pode ser - o que devo mudar nele? E o que explicar mais detalhadamente?

Aqui vem o rascunho:

• As chaves primárias precisam restringir qualquer tabela no banco de dados.
• Sem PK, uma tabela considerada como um heap e o SQL Server tem usos muito limitados desse tipo de dados - a única coisa que devo dizer que é adequada - um buffer para carregamento rápido de dados em massa de fora do mecanismo do SQL Server.
• Evite usar chaves primárias naturais. Principalmente por causa de suas distribuições naturais (gauss). Por exemplo, na tabela PhoneBook com chave primária baseada em Família e Nome haverá muitos Smiths e Wilsons e muito menos Zimmerbergs e isso indica que páginas contendo Smiths e Wilsons serão divididas com mais frequência do que outras páginas e consultadas também com mais frequência - o que multiplica o impacto no desempenho. Isso leva à degradação do desempenho, devido ao preenchimento da página da chave primária e a maioria das pesquisas atingirá as páginas esparsas do PK.

Além disso, mesmo usando SSN ou ID Number, que têm (espero) distribuição plana, como PK não resolve o problema de divisão de página do PK, porque esses números não estão em nenhuma ordem organizada.

• Secundário - PKs naturais são frequentemente compostos. Isso cria chaves estrangeiras compostas e índices amplos e, como resultado, prejudica o desempenho. Então, ...
• Evite usar PKs compostos. Melhor usar PK substituto simples e índice UNIQUE composto, do que PK composto completo, porque leva a FK composto e índices amplos devido à declaração de que todo índice secundário na tabela com PK deve incluir PK inteiro.
• Evite usar chaves primárias substitutas diferentes dos tipos inteiro ou identificador único
• Durante a fase de projeto do banco de dados, é muito importante identificar as entidades e tabelas correspondentes que podem ter em perspectiva "zilhões" de linhas, ou tabelas cujas chaves devem ser NÃO APENAS únicas em toda a tabela, mas únicas no banco de dados ou mesmo no mundo, ou que devem ser unido a outras tabelas por esta chave em várias tabelas de salto - é melhor esta tabela ter UUID PK, outras - inteiro comum, porque o SQL Server está muito bem ajustado para usar PKs inteiros.
• Esses dois tipos podem garantir tanto a distribuição vetorial (IDENTITY ou NEWSEQUENTIALID()) quanto a sequência monótona.
• Regra principal de design do banco de dados - Vinte minutos gastos em um design bem pensado economizarão dias ou até semanas durante a manutenção do banco de dados de produção