Chaves primárias e chaves estrangeiras são a cola que organiza múltiplas tabelas em um banco de dados relacional eficiente. O design das chaves primárias e das chaves estrangeiras tem um impacto decisivo no desempenho e na disponibilidade da base de dados física.
O esquema do banco de dados deve ser convertido de um projeto lógico teórico para um projeto físico real. A estrutura das chaves primárias e estrangeiras é o cerne deste processo de design. Uma vez que o banco de dados projetado seja utilizado em um ambiente de produção, será difícil modificar essas chaves, por isso é muito necessário e vale a pena projetar as chaves primárias e estrangeiras durante a fase de desenvolvimento.
Chave primária:
Os bancos de dados relacionais dependem de chaves primárias – a base do esquema físico do banco de dados. As chaves primárias têm apenas duas finalidades no nível físico:
1. Identifique uma linha de maneira exclusiva.
2. Como um objeto que pode ser efetivamente referenciado por chaves estrangeiras.
Com base nos dois usos acima, aqui estão alguns princípios que sigo ao projetar chaves primárias no nível físico:
1. A chave primária não deve ter sentido para o usuário. Se um usuário vê dados em uma tabela de junção que representa um relacionamento muitos-para-muitos e reclama que são de pouca utilidade, isso prova que sua chave primária está bem projetada.
2. A chave primária deve ser uma única coluna para melhorar a eficiência das operações de junção e filtragem.
Nota: As pessoas que usam chaves compostas geralmente pedem licença por dois motivos, ambos errados. Uma delas é que a chave primária deve ter um significado real. No entanto, tornar a chave primária significativa apenas proporciona conveniência para destruir artificialmente o banco de dados. A segunda é que você pode usar esse método para usar duas chaves estrangeiras como chaves primárias em uma tabela de junção que descreve um relacionamento muitos para muitos. Também me oponho a essa abordagem porque: chaves primárias compostas geralmente levam a chaves estrangeiras ruins, isto é, ao unir tabelas Torne-se a tabela mestre de outra tabela escrava e torne-se parte da chave primária desta tabela de acordo com o segundo método acima. No entanto, esta tabela pode se tornar a tabela mestre de outras tabelas escravas e sua chave primária. pode se tornar a tabela mestre de outras tabelas escravas Como parte da chave primária, se for transmitida dessa forma, quanto mais recente for a tabela escrava, mais colunas sua chave primária conterá.
3. Nunca atualize as chaves primárias. Na verdade, como a chave primária não tem outra finalidade senão identificar exclusivamente uma linha, não há razão para atualizá-la. Se a chave primária precisar ser atualizada, o princípio de que a chave primária não deve ter sentido para o usuário será violado.
Nota: Este princípio não se aplica a dados que muitas vezes precisam ser organizados durante a conversão de dados ou fusões de vários bancos de dados.
4. A chave primária não deve conter dados que mudam dinamicamente, como carimbo de data/hora, coluna de horário de criação, coluna de horário de modificação, etc.
5. A chave primária deve ser gerada automaticamente pelo computador. Se um ser humano intervém na criação de uma chave primária, isso terá outro significado além de identificar exclusivamente uma linha. Uma vez ultrapassada esta fronteira, poderá haver um incentivo para modificar a chave primária, de modo que os meios de chave utilizados por este sistema para ligar e gerir linhas de registos caiam nas mãos de pessoas que não compreendem a concepção de bases de dados.
Uma chave estrangeira é uma restrição de integridade no nível do banco de dados, que é o método de implementação do banco de dados de "integridade referencial" mencionado no livro básico de teoria do banco de dados.
É claro que o atributo chave estrangeira pode ser removido se você não quiser mais usar essa restrição, certamente não terá nenhum impacto na programação, mas ao inserir os dados, a verificação de "integridade referencial" não será realizada nos dados inseridos. .
Por exemplo, existem duas tabelas
A(a,b): a é a chave primária, b é a chave estrangeira (de Bb)
B (b, c, d): b é a chave primária
Se eu remover o atributo de chave estrangeira do campo b, isso não terá impacto na programação.
Como acima, b em A está vazio ou é um valor que existe em b em B. Quando há uma chave estrangeira, o banco de dados verificará automaticamente se b em A existe em b em B.
1. A expressão externa expressa integridade referencial: é inerente aos dados e nada tem a ver com o programa. Portanto, deve ser deixado para o SGBD.
2. O uso de bancos de dados externos é simples e intuitivo e pode ser refletido diretamente no modelo de dados. Tem grandes benefícios em termos de design, manutenção, etc., especialmente ao analisar bancos de dados existentes. há muito tempo, encontrei um banco de dados corporativo existente. Algumas das restrições de integridade referencial nele são descritas por chaves estrangeiras e algumas são implementadas usando gatilhos. Claro, pode estar no documento, mas pode não estar completo, mas as chaves estrangeiras são muito óbvias e intuitivas.
3. Como podemos usar gatilhos ou programas para concluir este trabalho (referindo-se às restrições de integridade referencial), o SGBD forneceu os meios, por que deveríamos fazer isso nós mesmos? E deve-se dizer que o que fazemos não é tão bom quanto o RDBMS. Na verdade, os primeiros RDBMS não tinham chaves estrangeiras, mas agora todos as possuem. Acho que faz sentido que os fornecedores de bancos de dados adicionem esse recurso. Desta perspectiva, as chaves estrangeiras são mais convenientes.
4. Em relação à conveniência, com base nos projetos que liderei, os programadores relataram que era principalmente problemático inserir dados durante a depuração: se os dados podem violar a integridade referencial, então a integridade referencial em si não entra em conflito com o negócio de reputação neste momento, o programa de futuros de gatilho não deve ser utilizado, caso contrário, significa que os dados estão errados e não devem ser introduzidos na base de dados! Além disso, isto também deveria fazer parte do sistema de teste: bloquear dados ilegais. Na verdade, o programa front-end deveria lidar com essa falha de envio. Os dados pertencem à empresa, não ao programa. Os programas armazenados devem ser separados dos dados tanto quanto possível e vice-versa.
Por fim, deixe-me falar sobre vários princípios para a construção de chaves:
1. Crie chaves estrangeiras para campos relacionados.
2. Todas as chaves devem ser exclusivas.
3. Evite usar chaves compostas.
4. As chaves estrangeiras estão sempre associadas a campos-chave exclusivos.
Este artigo vem do blog CSDN. Indique a fonte ao reimprimir: http://blog.csdn.net/c04s31602/archive/2009/12/30/5107568.aspx .