Início / dba / Perguntas / 106539
Accepted
dsaxton
Asked: 2015-07-10 20:24:54 +0800 CST

Por que uma chave deve ser explícita?

  • 772

Sou muito novo no assunto de bancos de dados, então isso pode parecer ignorante, mas estou curioso para saber por que uma chave deve ser explícita em uma tabela. Isso é principalmente para informar ao usuário que o valor da coluna fornecido é (esperançosamente) exclusivo em cada linha? A singularidade ainda deve estar lá, mesmo que não seja mencionada.

primary-key unique-constraint

4 respostas

  1. Best Answer

    Obviamente, você está sugerindo que os CONSTRAINTs em um banco de dados devem ser aplicados pelo (s) aplicativo (s) que acessam esse banco de dados?

    Existem muitas razões pelas quais esta é uma ideia ruim (ruim, ruim...).

    1) Se você está construindo um "mecanismo" de restrição "roll-your-own" (ou seja, dentro do código do seu aplicativo), então você está apenas emulando o que Oracle/SQL Server/MySQL/PostgreSQL/<.whoever...> gastaram anos escrevendo. Seu código CONSTRAINT foi testado ao longo desses anos por literalmente milhões de usuários finais.

    2) Com todo o respeito a você e sua equipe, você não vai acertar nem em questão de anos - a partir daqui , o código MySQL sozinho custou 40 milhões de dólares. E o MySQL é o mais barato dos 3 servidores acima, e eles nem implementam CHECK CONSTRAINTs. Obviamente, obter RI (Integridade Referencial) completamente correto é difícil.

    Eu costumava frequentar os fóruns da Oracle e não posso te dizer quantas vezes algum gerente/programador pobre teve um projeto lançado sobre ele onde o gênio que tinha seu trabalho antes teve a "brilhante" ideia de fazer o que você sugere .

    Jonathan Lewis (ele escreveu um livro de 550 páginas sobre os fundamentos do otimizador Oracle ) dá como não. 2 de seus Desastres de Design em outro livro (" Tales of the Oak Table " - a Oak Table é um grupo de especialistas em Oracle) é

    1. Verificaremos a integridade dos dados no nível do aplicativo, em vez de aproveitar as vantagens das capacidades de verificação de restrições do Oracle.

    3) Mesmo que por algum milagre você possa implementar RI corretamente, você terá que reimplementá-lo completamente uma e outra vez para cada aplicativo que toca esse banco de dados - e se seus dados forem importantes, novos aplicativos o farão. Escolher isso como um paradigma levará você e seus colegas programadores (para não mencionar a equipe de suporte e vendas) a uma vida de constante combate a incêndios e miséria.

    Você pode ler mais sobre por que implementar CONSTRAINTs de dados no nível do aplicativo é uma loucura aqui , aqui e aqui .

    Para responder especificamente à sua pergunta:

    Por que eles são declarados? Parece muito útil, mas é realmente necessário ter um banco de dados que funcione

    A razão pela qual KEYs (seja PRIMARY, FOREIGN, UNIQUEou apenas es comuns INDEX) são declarados é que, embora não seja estritamente necessário que um banco de dados os tenha para funcionar, é absolutamente necessário que eles sejam declarados para que funcione bem .

    • 32

  2. Quando você cria uma chave em um banco de dados, o mecanismo do DBMS impõe uma restrição de exclusividade nos atributos da chave. Isso serve a pelo menos três propósitos relacionados:

    • Integridade dos dados: dados duplicados não podem ser inseridos em atributos-chave. Quaisquer dependências das chaves são, portanto, garantidas.
    • Identificação: os usuários podem confiar nas chaves como meio de identificar e atualizar os dados com precisão.
    • Otimização: as informações (metadados) sobre quais atributos são únicos estão disponíveis para o otimizador de consulta do DBMS. Essas informações permitem que o otimizador simplifique a execução da consulta de determinadas maneiras para que as consultas sejam executadas mais rapidamente.
    • 10

  3. Acrescentarei um aspecto às excelentes respostas existentes: Documentação. Freqüentemente, é importante ver quais tipos de chaves você pode usar para identificar uma entidade. Qualquer combinação de colunas exclusivas é uma chave candidata.

    A chave primária tende a ser um conceito especialmente útil na prática.

    Independentemente de você impor uma chave ou não (provavelmente deveria), a documentação é valiosa por si só.

    • 8

  4. Outra razão pela qual você deve usar CONSTRAINTs em vez de algum código interno do aplicativo:

    O que acontece se um desenvolvedor/dba usar uma instrução insert/update/delete para modificar os dados direto no banco de dados? Neste caso, toda a sua boa integridade referencial baseada em aplicativos será inútil. Eu sei, alguns desenvolvedores gostam da possibilidade de modificar dados diretamente sem ter que se preocupar com RI porque sabem o que fazem - pelo menos na maioria das vezes (mas nem sempre)

    PS: Claro que você poderia criar gatilhos, mas eles geralmente são muito lentos (em comparação com CONSTRAINTS).

    • 5

relate perguntas