Por que uma chave deve ser explicitada?

15

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.

primary-key unique-constraint

— dsaxton
fonte

Você quer dizer que, se você possui uma chave ÚNICA, por que se preocupar em ter uma chave PRIMÁRIA?

— Verace

1

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

— dsaxton

1

Eles não são necessários para que seu banco de dados funcione, mas são necessários para que seus dados "funcionem", isto é, sejam consistentes, porque é exatamente assim que você está dizendo ao servidor de banco de dados para manter as informações consistentes.

— 187 Andriy M

Se o banco de dados souber que um determinado campo é uma chave, um efeito colateral é que ele pode ajudá-lo a localizar a linha que contém a chave muito mais rapidamente do que se precisar examinar todas as linhas nas tabelas. Os índices são uma parte muito importante do motivo pelo qual os bancos de dados são úteis.

— Thorbjørn Ravn Andersen

32

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) é

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 .

— Vérace
fonte

1

Obrigado pela sua resposta. Provavelmente precisarei aprender mais para entender completamente. (Eu realmente não pertencem a uma equipe, eu só estou aprendendo sobre bancos de dados por curiosidade.)

— dsaxton

2

Leia alguns livros (Data, Garcia-Molina ...) e volte para nós se tiver perguntas específicas (perguntas excessivamente amplas são consideradas fora de tópico aqui). ps Bem-vindo ao fórum :-)

— Vérace

Embora eu nunca sugira que você não coloque restrições no banco de dados (você sempre deve ter uma chave primária e chaves estrangeiras no mínimo), você pode evitar o número 3 ao ter todos os aplicativos consumidos de um serviço compartilhado (arquitetura orientada a serviços ) (Isso é provavelmente algo que você deve considerar para vários consumidores, de qualquer maneira, como fazer cada último integridade verificar que você precisa no banco de dados pode obter pesadelo, também Pense gatilhos em todos os lugares fazendo verificações em tabelas e linhas o tempo todo..)

— jpmc26

10

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.

— nvogel
fonte

8

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ó.

— boot4life
fonte

1

Diagramas de banco de dados! A primeira coisa que sempre faço quando é solicitado a dizer algo significativo sobre o software com o qual não estou familiarizado é ver se ele usa um banco de dados relacional e, se o faz, tenta criar um diagrama de banco de dados. Isso me dará uma excelente idéia das informações com as quais o aplicativo trabalha. Infelizmente, 90% dos bancos de dados que eu vi não declaram chaves estrangeiras; portanto, os diagramas são apenas conjuntos de tabelas. A dedução de chaves estrangeiras implícitas no nível do aplicativo requer adivinhação e ajustes.

— Reinierpost

1

@reinierpost Concordo plenamente. Os dados são o objeto mais valioso para documentar e manter limpo, porque persiste para sempre. Código pode mudar; tende a ser mais transitório.

— Boot4life

@reinierpost - consultei uma empresa que fornecia software para toda a infraestrutura ferroviária de um grande país europeu (grande - pense em bilhões de widgets) e eu disse: "Hum, vou fazer uma consulta para verificar as FOREIGN KEYdefinições para obter um sinta pelo sistema ". Minha consulta retornou zip !!! Claro que meu SQL deve estar errado, mencionei isso para um dos programadores seniores. Com orgulho (não menos), ele anunciou (como se estivesse apresentando um filho recém-nascido) que o sistema não possui nenhum FK porque "todas as pesquisas estão em PRIMARY KEYs" - (irrelevante). <Doh ...> à la Homer Simpson!

— Vérace

5

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).

— Thomas Franz
fonte