Chave exclusiva ou primária do endereço de e-mail?

Eu sou um novato em bancos de dados. Eu li e descobri que provavelmente não é uma boa idéia usar o endereço de email como chave primária, porque as comparações de string são mais lentas, o que afeta o desempenho em junções complexas e, se um email mudar, eu teria que alterar todas as chaves estrangeiras, o que exige muito de esforço.

Mas se minha tabela de usuários exigir que todos os usuários tenham um endereço de email e cada um desses endereços seja único, será suficiente adicionar um índice exclusivo na coluna de email? Como os campos exclusivos do afaik permitem valores nulos, enquanto eu exijo que todo usuário tenha um endereço de email, não permitindo valores nulos. Há algo que estou perdendo aqui? Ou eu suponho que a coluna de email seja única e verifique durante a validação de dados no servidor que o usuário insira um endereço de email para que todo usuário tenha um?

Vamos primeiro distinguir entre chaves e índices, a chave faz parte do modelo lógico e é frequentemente implementada com um índice exclusivo. No entanto, você pode criar um índice exclusivo sem criar uma chave, mas isso não pode ser referenciado por uma chave estrangeira.

Uma chave candidata é algo que identifica exclusivamente uma linha em uma tabela. No SQL, uma das chaves candidatas é normalmente usada como chave primária (nunca entendi realmente por que uma das ck é considerada "melhor" que as outras, mas essa é outra). história), e o ck restante se torna restrições únicas.

Uma restrição exclusiva pode ser usada da mesma maneira que uma chave primária. Considerar:

create table A ( x ... not null
               , y ... not null
               , z ... not null
               ,     unique (x)
               ,     primary key (y,z) );

create table B ( x ...
               ,   ...
               ,     foreign key (x) references A (x) );

create table C ( y ...
               , z ...
               ,   ...
               ,     foreign key (y, z) references A (y, z) );  

B faz referência à restrição exclusiva e C faz referência à restrição de chave primária.

NOT NULL é outro tipo de restrição. No seu caso, você pode aplicar isso a emails sem declará-los únicos.

O próximo aspecto da sua postagem diz respeito à estabilidade de uma chave, uma chave deve ser estável (mas isso não significa que ela nunca pode mudar, não precisa ser imutável). Alguns DBMS implementam o ON UPDATE CASCADE que podem ser úteis para essa operação, ainda que a chave seja distribuída em torno do seu modelo, será difícil atualizá-lo.

No seu caso, eu provavelmente escolheria outra chave candidata como chave primária e declararia o email como NOT NULL e UNIQUE.

Sim, ter um índice exclusivo na coluna EmailAddress deve estar ok. O único problema seria se alguém desistisse do endereço de email depois de se inscrever no serviço, mas não lhe dissesse, quem quer que o proprietário do endereço de email tente se inscrever. Mas esse é um caso bastante raro.

Se um índice exclusivo permite valores nulos que dependem da sua plataforma de banco de dados. Oracle faz, o SQL Server permite um único valor NULL. Você pode resolver isso fazendo a coluna não permitir valores NULL e construindo o índice exclusivo nela.

Ter o índice exclusivo no EmailAddress é bom.

Como você já declarou que existe uma validação em seu aplicativo por ter o Endereço de email como campo obrigatório, eu diria que a outra validação seria do banco de dados não aceita um usuário sem um endereço de email e evita a entrada duplicada também e essa validação será imposto com este índice exclusivo.

Conforme declarado em outra resposta do SQL Server, você precisa criar uma coluna para não permitir valor nulo antes de criar índices exclusivos.