Necessidade de chave estrangeira, neste caso (innoDB / mysql)

Question

i recentemente migrou toda a minha DB a partir myisam para InnoDB. Eu sou bastante novo para tudo isso, então eu tenho uma pergunta sobre o uso da chave estrangeira.

Vamos dizer que eu tenho duas tabelas:. Usuários, mensagens

usuários

id (pr_key)
name

mensagens

id (pr_key)
user_id
message

Os campos de identificação são ambos auto incrementado.

Então, agora em minhas consultas i juntar esses 2 mesas já. Ainda é necessário colocar uma chave estrangeira aqui, eu realmente não vejo um ponto. Será que ela tem benefícios de desempenho.

Se eu optar por colocar uma chave estrangeira aqui eu supor que eu tenho para fazer a pr_key de mensagens ambos id, e user_id.

Will adicionando outro prim_key não basta ter mais espaço, e resultando em um desempenho mais lento.

Agora, se a tabela tem duas pr_keys, e eu só consulta em um deles, vai ainda tenho os mesmos benefícios de desempenho. Ou eu preciso explicitamente usar as duas chaves.

Eu sei que, neste exemplo, eu vou estar à procura em user_id por isso é talvez inteligente para indexar isso de qualquer maneira. Mas e se o campo é um campo onde não existem pesquisas sobre. Ainda é bom colocar uma chave primária múltipla neste campo, apenas para o hey relação estrangeiro.

Obrigado!

Answer 1

Tem integridade dos dados benefícios.

ele irá parar o código do aplicativo de entrar user_id de 1234 na tabela de mensagens quando não há usuário com id = 1234 na tabela de usuários. E ele vai parar a aplicação de excluir usuário quando o usuário tem quaisquer mensagens contidas na tabela de mensagens.

Nome do PK não tem que coincidir com o nome do FK na tabela criança referência.

"Se eu optar por colocar uma chave estrangeira aqui eu supor que eu tenho para fazer a pr_key de mensagens ambos id, e user_id."

NÃO . Você não muda a chave na tabela de mensagens, basta estabelecer uma restrição de chave estrangeira (FK) na coluna User_Id na tabela de mensagens, que faz referência (aponta para) a coluna id na tabela de usuários. Não PK adicional é necessária em mensagens, e desde PK já é única (você não pode ter duas mensagens com o mesmo messageId), tornando o PK em ambos id e user_id não pode adicionar mais singularidade.)

A linha inferior aqui é que você pode ter um equívoco fundamental sobre o que é uma chave primária e uma chave estrangeira realmente são.

• A PK é uma restrição na singularidade de uma linha, que requer um índice.
• A FK é uma restrição sobre o valor de uma coluna (que determina que a exist valor como um valor PK em alguma outra tabela referenciada) Faz não requer um índice.

@Noah, confira este Outra questão SO

Answer 2

Se você estabelecer uma regra FOREIGN KEY formal sobre mensagens (user_id) ou não, o fato é que este é um relacionamento de chave estrangeira.

Em primeiro lugar, lembre-se que uma chave primária adequada sobre uma mesa devem ser suficientes para identificar exclusivamente cada registro na tabela. Considerando que cada mensagem já terá que com o campo id, você não precisa nem você particularmente quer envolver o user_id na chave primária da tabela de mensagens.

Em segundo lugar, como Charles já foi dito declarando uma chave estrangeira em mensagens (user_id) que os usuários referências (id) lhe permitirá garantir a integridade de seus dados. Usando uma restrição de chave estrangeira, você pode especificar o que fazer quando um registro na tabela de usuários é excluído que tem registros correspondentes na tabela de mensagens. Suas opções são ON DELETE CASCADE (apagar todos os registros filho para este registo de utilizador), ON DELETE RESTRICT (não permitir que um usuário a ser excluído que tem registros na tabela de mensagens), ON DELETE NO ACTION (ignore operações de exclusão) , ON DELETE SET NULL (preserva os registros filho, mas define o campo user_id para NULL).

Cada uma destas opções é apropriado, dependendo das circunstâncias, mas a coisa mais importante aqui é que você pode prevenir ponteiros nulos inesperados da tabela filho para a tabela pai.

Em terceiro lugar, estabelecer a relação FOREIGN KEY irá proporcionar ganhos de desempenho, pois isso irá gerar um índice em mensagens (user_id) que corresponde com a chave primária na tabela de usuários. Ao realizar qualquer consulta que associa nesses campos, você verá que o número de registros que tem que consultado para retornar os registros filho é substancialmente reduzido, em comparação com não ter a chave estrangeira estabelecida.

@Charles Bretana - A pergunta que você conectar-se a é específico para Microsoft SQL Server. A questão aqui é a respeito de MySQL / InnoDB.

Eu recomendo que você olhar para a documentação para InnoDB chave Foreign Restrições .

InnoDB requer índices em estrangeiro chaves e chaves referenciados para que verificação de chaves estrangeiras pode ser rápido e não requerem uma verificação de tabela. No faz referência à tabela, deve haver um índice onde as colunas de chaves estrangeiras são listados como as primeiras colunas da mesma ordem. índice de um tal é criado sobre a mesa fazendo referência automaticamente se ele não existe. (Isto é, em contraste com algumas versões mais antigas, em índices que teve de ser criado explícita ou a criação de estrangeiro restrições de chave falharia.) nome_do_índice, se for dado, é utilizado como descrito anteriormente.