Tática de normalização do servidor SQL: varchar vs int identidade

Question

Só estou me perguntando qual é a solução ideal aqui.

Digamos que eu tenho um banco de dados normalizado. A chave primária de todo o sistema é um varchar. O que estou me perguntando é que devo relacionar esse Varchar a um INT para a normalização ou deixá -lo? É mais simples sair como um Varchar, mas pode ser mais ideal

Por exemplo, eu posso ter

People
======================
name      varchar(10)   
DoB       DateTime    
Height    int  

Phone_Number
======================
name      varchar(10)   
number    varchar(15)

Ou eu poderia ter

People
======================
id        int Identity   
name      varchar(10)   
DoB       DateTime  
Height    int  

Phone_Number
======================
id        int   
number    varchar(15)  

Adicione vários outros relacionamentos individuais, é claro.

O que vocês acham? Qual é melhor e por que?

Answer 1

Você pode realmente usar nomes como chaves primárias? Não existe um alto risco de várias pessoas com o mesmo nome?

Se você realmente tiver tanta sorte que seu atributo de nome possa ser usado como chave primária, então - por todos os meios - use isso. Muitas vezes, porém, você terá que inventar algo, como um cliente_id, etc.

E finalmente: "Nome" é uma palavra reservada em pelo menos um DBMS; portanto, considere usar outra coisa, por exemplo, Nome Fulln.

Answer 2

Acredito que a maioria das pessoas que desenvolveram aplicativos de banco de dados do mundo real de tamanho real lhe dirá que as chaves substitutas são a única solução realista.
Sei que a comunidade acadêmica discordará, mas essa é a diferença entre pureza teórica e praticidade.

Qualquer consulta de tamanho razoável que precise fazer junções entre tabelas que usam teclas que não são de surrogato, onde algumas tabelas têm teclas primárias compostas rapidamente se tornam inalteráveis.

Answer 3

Usar qualquer tipo de dados não sintéticos (ou seja, qualquer coisa do usuário, em oposição ao gerado pelo aplicativo) como PK é problemático; Você precisa se preocupar com as diferenças de cultura/localização, sensibilidade ao caso (e outros problemas, dependendo do agrupamento de banco de dados), pode resultar em problemas de dados se/quando esses dados entre o usuário mudarem, etc.

O uso de dados não gerados por usuários (GUIDs seqüenciais (ou não sequencial se o seu banco de dados não os suportar ou você não se importa com divisões de página) ou identidade INTS (se você não precisar de Guids)) é muito mais fácil e muito mais seguro.

Em relação aos dados duplicados: não vejo como o uso de teclas não sintéticas o protege disso. Você ainda tem problemas em que o usuário entra "Bob Smith" em vez de "Bob K. Smith" ou "Smith, Bob" ou "Bob Smith" etc. O gerenciamento de duplicação é necessário (e praticamente idêntico), independentemente de sua chave ser sintética ou as chaves não sintéticas e não sintéticas têm uma série de outros problemas em potencial que as chaves sintéticas evitam ordenadamente.

Muitos projetos não precisam se preocupar com isso (opções de agrupamento bem restritas evitam muitas delas, por exemplo), mas em geral prefiro chaves sintéticas. Isso não quer dizer que você não possa ter sucesso com as chaves orgânicas, claramente você pode, mas para muitos projetos eles não são a melhor escolha.

Answer 4

Eu acho que se o seu Varchar fosse maior, você perceberia que você está duplicando um pouco de dados em todo o banco de dados. Considerando que, se você foi com uma coluna de ID numérica, não está duplicando quase a mesma quantidade de dados ao adicionar colunas de teclas estrangeiras a outras tabelas.

Além disso, dados textuais são uma dor real em termos de comparações, sua vida é muito mais fácil quando você está fazendo Onde id = user_id contra Onde nome como inputName (ou algo semelhante).

Answer 5

Se o campo "Nome" for realmente apropriado como chave primária, faça -o. O banco de dados irá não Seja mais normalizado criando uma chave substituta nesse caso. Você receberá algumas cordas duplicadas para chaves estrangeiras, mas isso não é uma questão de normalização, pois a integridade dos guarrantes de restrição de FK em cordas exatamente como faria nas teclas substitutos.

No entanto, você não está explicando qual é o "nome". Na prática, raramente é que uma string é apropriada como chave primária. Se for o nome de uma pessoa, não funcionará como PK, pois mais de uma pessoa pode ter o mesmo nome, as pessoas podem mudar de nome e assim por diante.

Answer 6

Uma coisa que outros parecem não ter mencionado é que as junções nos campos int tendem a ter um desempenho melhor do que as junções nos campos de varchar.

E eu definitivamente sempre usaria uma chave substituta sobre o uso de nomes (de pessoas ou empresas) porque elas nunca são únicas ao longo do tempo. Em nosso banco de dados, por exemplo, temos 164 nomes com mais de 100 instâncias com o mesmo nome. Isso mostra claramente os perigos de considerar usar o nome como um campo -chave.

Answer 7

A pergunta original não é de normalização. Se você possui um banco de dados normalizado, como declarou, não precisa alterá -lo por motivos de normalização.

Existem realmente dois problemas em sua pergunta. O primeiro é se o INTS ou o VARCHARS é preferível para uso como chaves primárias e chaves estrangeiras. A segunda é se você pode usar as teclas naturais fornecidas na definição do problema ou se deve gerar uma chave sintética (chave substituta) para substituir a chave natural.

Os INTs são um pouco mais concisos que os varchars e um pouco mais eficientes para coisas como processamento de índices. Mas a diferença não é esmagadora. Você provavelmente não deve tomar sua decisão apenas sobre essa base.

A questão de saber se a chave natural fornecida realmente funciona como uma chave natural ou não é muito mais significativa. O problema das duplicatas em uma coluna "nome" não é o único problema. Há também o problema do que acontece quando uma pessoa muda de nome. Esse problema provavelmente não aparece no exemplo que você deu, mas aparece em muitos outros aplicativos de banco de dados. Um exemplo seria a transcrição em quatro anos de todos os cursos realizados por um aluno. Uma mulher pode se casar e mudar o nome dela no decorrer de quatro anos, e agora você está preso.

Você precisa deixar o nome inalterado; nesse caso, ele não concorda mais com o mundo real ou atualizá -lo retroativamente em todos os cursos que a pessoa fez, o que faz com que o banco de dados discorde das listas impressas feitas na época.

Se você decidir sobre uma chave sintética, agora precisa decidir se o aplicativo revelará ou não o valor da chave sintética para a comunidade de usuários. Essa é outra lata inteira de vermes e além do escopo desta discussão.