Por que uma chave deve ser explicitada?

Sou muito novo no assunto de bancos de dados, portanto isso pode parecer ignorante, mas estou curioso para saber por que uma chave deve ser explicitada em uma tabela. Isso é principalmente para informar ao usuário que, com sorte, é garantido que o valor da coluna seja único em cada linha? A singularidade ainda deve estar presente, mesmo que não seja mencionada.

Você está obviamente sugerindo que CONSTRAINTs em um banco de dados devem ser aplicados pelos aplicativos que / quais acessam esse banco de dados?

Há muitas razões pelas quais essa é uma má idéia (ruim, ruim ...).

1) Se você estiver construindo um mecanismo de restrição "role-your-own" (ou seja, dentro do código do aplicativo), estará apenas simulando o que o Oracle / SQL Server / MySQL / PostgreSQL / <. Quem ... ...> gastou anos escrevendo. Seu código CONSTRAINT foi testado nesses anos por literalmente milhões de usuários finais.

2) Com todo o respeito por você e sua equipe, você não conseguirá acertar nem em questão de anos - desde daqui , apenas o código MySQL custa 40 milhões de dólares. E o MySQL é o mais barato dos 3 servidores acima, e eles nem implementam CHECK CONSTRAINTs. Obviamente, é difícil acertar no RI (Integridade Referencial).

Eu costumava frequentar os fóruns da Oracle e não sei dizer quantas vezes um gerente / programador pobre teve um projeto sobre ele, onde o gênio que já havia trabalhado antes tinha a idéia "brilhante" de fazer o que você sugere .

Jonathan Lewis (ele escreveu um livro de 550 páginas sobre os fundamentos do otimizador da Oracle ) dá como não. 2 de seus desastres de design em outro livro (" Contos da mesa de carvalho " - a mesa de carvalho é um grupo de especialistas em Oracle) é

2. Verificaremos a integridade dos dados no nível do aplicativo, em vez de tirar proveito das habilidades de verificação de restrições da Oracle.

3) Mesmo se por algum milagre você pode implementar adequadamente RI, você terá que completamente reimplementá-lo uma e outra vez para todos os aplicativos que tocarem nesse banco de dados - e se seus dados forem importantes, novos aplicativos serão . Escolher isso como paradigma levará você e seus colegas programadores (para não mencionar a equipe de suporte e as vendas) a uma vida de constante combate e miséria.

Você pode ler mais sobre por que implementar CONSTRAINTs de dados no nível do aplicativo não é nada menos do que 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 (quer PRIMARY, FOREIGN, UNIQUEou apenas comum INDEXes) são declarados é que, embora seja não estritamente necessário para um banco de dados para tê-los para isso funcionar, é absolutamente necessário para que sejam declarados para que ela funcione bem .

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

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

Vou adicionar um aspecto às excelentes respostas existentes: Documentação. Frequentemente, é importante ver que 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.

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

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 diretamente no banco de dados? Nesse caso, toda a integridade referencial baseada em aplicativo agradável será inútil. Eu sei que alguns desenvolvedores gostam da possibilidade de modificar dados diretamente sem precisar se preocupar com o RI porque sabem o que fazem - pelo menos na maioria das vezes (mas nem sempre)

PS: Claro que você pode criar gatilhos, mas eles geralmente são terrivelmente lentos (em comparação com as restrições).